Creazione di un collegamento reale - Autorizzazioni?

Quali autorizzazioni influiscono sulla creazione di un collegamento reale? La proprietà dei file è importante?

Supponiamo che l'utente alicedesideri creare un collegamento reale al file target.txtin una directory target-dir.

Quali autorizzazioni sono alicenecessarie per entrambi target.txte target-dir?
Se target.txtè di proprietà dell'utente billed target-dirè di proprietà dell'utente chad, cambia qualcosa?

Ho provato a simulare questa situazione creando la seguente struttura di cartelle / file in un ext4filesystem:

#> ls -lh . *
.:
drwxr-xr-x 2 bill bill 60 Oct  1 11:29 source-dir
drwxrwxrwx 2 chad chad 60 Oct  1 11:40 target-dir

source-dir:
-r--r--r-- 1 bill bill 0 Oct  1 11:29 target.txt

target-dir:
-rw-rw-r-- 1 alice alice 0 Oct  1 11:40 dummy

Sebbene alicepossa creare un collegamento diretto a target.txt, non può creare un collegamento reale:

#> ln source-dir/target.txt target-dir/
ln: failed to create hard link ‘target-dir/target.txt’ => ‘source-dir/target.txt’: Operation not permitted

Se le aliceproprietà target.txte nessuna autorizzazione vengono modificate, il collegamento reale ha esito positivo. Cosa mi sto perdendo qui?

linux permissions hard-link

— gcscaglia
fonte

È per un incarico? Può influire sul tipo di risposte che alcuni sceglieranno di dare in tal caso (non che sarebbe fuori dai limiti porre una domanda su un incarico ovviamente). Ad ogni modo, hai provato a creare quello scenario e vedere cosa succede?

— Eric Renouf,

No, non è per un incarico. Sto affrontando questo scenario esatto e ho alcune ipotesi, ma ho pensato che sarebbe meglio chiedere da un punto di vista teorico. Nel mio caso non sono in grado di creare l'hard-link indipendentemente dalle autorizzazioni target.txte target-dir, a meno che non sudosia un utente root.

— gcscaglia,

I collegamenti fissi condividono la stessa proprietà e le stesse autorizzazioni, quindi è uguale all'accesso al file originale.

— teppic

@teppic Il mio difficile non sta accedendo al collegamento reale creato, sta creando il collegamento alicereale come . Posso accedere sia al file originale sia a un collegamento reale (creato con sudo), ma non riesco a creare il collegamento come l'utente alicenonostante tutti concordiamo queste autorizzazioni dovrebbe essere sufficiente per questo.

— gcscaglia,

Risposte:

Per creare il collegamento alicereale sono necessarie write+executeautorizzazioni target-dirsu tutti i casi. Le autorizzazioni necessarie su target.txtvarieranno:

Se fs.protected_hardlinks = 1quindi alicenecessita della proprietà target.txto almeno delle read+writeautorizzazioni su di esso.
In fs.protected_hardlinks = 0tal caso, qualsiasi set di autorizzazioni farà; Anche 000 va bene.

Questa risposta a una domanda simile conteneva le informazioni mancanti per rispondere a questa domanda.

Da http://kernel.opensuse.org/cgit/kernel/commit/?id=800179c9b8a1 [sottolineatura mia]:

hardlinks:

Sui sistemi che hanno directory scrivibili dall'utente sulla stessa partizione dei file di sistema, una classe di problemi di sicurezza di lunga data è la corsa basata sul tempo di controllo del tempo di utilizzo basata su hardlink, più comunemente vista nelle directory scrivibili dal mondo come / tmp. Il metodo comune di sfruttamento di questo difetto è quello di oltrepassare i confini dei privilegi quando si segue un dato hardlink (ovvero un processo di root segue un hardlink creato da un altro utente). Inoltre, esiste un problema in cui gli utenti possono "bloccare" un file setuid / setgid potenzialmente vulnerabile in modo che un amministratore non esegua effettivamente l'aggiornamento completo di un sistema.

La soluzione è quella di consentire la creazione di hardlink solo quando l'utente è già proprietario del file esistente o se hanno già accesso in lettura / scrittura al file esistente .

— gcscaglia
fonte

Grazie! Questo è ciò che ho lottato per un giorno su Debian 9!

— Arda,

Perché dovrei ottenere "operazione non consentita" anche quando ho i permessi rwx sulla directory e i permessi rw sul file?

— Michael,

alicenecessita almeno dell'autorizzazione di lettura target.txte di scrittura + esecuzione dell'autorizzazione su target-dir.

Ora, la struttura delle autorizzazioni funziona come un insieme separato triplo:

Autorizzazioni utente: si applicano all'utente proprietario del nodo.
Autorizzazioni di gruppo: si applicano a qualsiasi utente appartenente al gruppo proprietario del nodo.
Autorizzazioni di altri: si applicano a qualsiasi altro utente / gruppo che non possiede il nodo.

Pertanto, la domanda di proprietà riguarda solo in quale set di autorizzazioni sono le autorizzazioni richieste alice, essendo:

Se aliceè l'utente proprietario, le autorizzazioni necessarie devono trovarsi nella parte "utente".
Se alicefa parte del gruppo proprietario, le autorizzazioni necessarie devono trovarsi nella parte "gruppo".
Se alicenon lo possiede e non fa parte del gruppo che lo possiede, le autorizzazioni necessarie devono trovarsi nella parte "altra".

— dave_alcarin
fonte

L'ho pensato anch'io. Ma nella mia situazione target.txtha 444 permessi e target-dirha 777 permessi ma non riesco a creare un hard-link a meno che non lo faccia come root o possiedo il file a cui mi sto collegando. Stranamente, un morbido -link funzionerà come si descrive.

— gcscaglia,

Che informazione sarebbe utile avere nella domanda stessa, ti consiglio di aggiornare. Stranamente non ci avevo pensato prima ... ma il file system su cui stai lavorando supporta proprietà / permessi simili a Unix, per cominciare?

— dave_alcarin,

Sì, è un ext4 out-of-the-box su un sistema fedora 21; Il collegamento funziona quando sono il proprietario del file.

— gcscaglia,