Perché cambiare il proprietario di un collegamento simbolico in linux?

12

In Linux è possibile cambiare il proprietario o il proprietario del gruppo di un collegamento simbolico (collegamento simbolico). Mi chiedevo perché qualcuno avrebbe voluto farlo, poiché le autorizzazioni di un collegamento simbolico non vengono utilizzate quando si accede a un file tramite esso.

Posso solo immaginare un caso d'uso in cui potrebbe essere utile: consentire a un utente di eliminare un collegamento simbolico in una directory con bit appiccicoso.

Conosci altri casi in cui potrebbe essere utile cambiare il proprietario o il proprietario del gruppo di un collegamento simbolico?

symlink

— user368507
fonte

6

Supponiamo che root stia funzionando in una directory in cui Eva può scrivere. C'è un file fooin questa directory che deve essere modificato per appartenere a Eva. Quindi i tipi di root chown eve foo. Ma poco prima che la radice colpisca Enter, Eva corre ln -sf /etc/passwd foo. Ora /etc/passwdappartiene a Eva! Se il root può essere eseguito chown -h eve fooper assicurarsi di non seguire i symlink, il danno più grave che si può fare è che qualche altro file nella stessa directory è stato modificato per appartenere a Eve.

lchownè utile anche quando si cambia il proprietario di un albero di directory. Non devi preoccuparti di influenzare accidentalmente un file all'esterno dell'albero perché hai chiamato chownun collegamento simbolico.

— Gilles 'SO- smetti di essere malvagio'
fonte

"Se root può eseguire chown -h bob foo per assicurarsi di non seguire i collegamenti simbolici, il danno più grave che si può fare è che qualche altro file nella stessa directory è stato modificato per appartenere a Eva.". Immagino che intendi "chown -h eve foo". L'altro file che potrebbe essere cambiato, è il collegamento simbolico, giusto?

— user368507

@ user5528 L'altro file potrebbe non essere un collegamento simbolico: Eva può ancora essere eseguita mv myfile fooe root finirà per cambiare il proprietario di myfile. Ma myfiledeve essere un file che Eva può creare o spostare in quella directory, non può essere alcun file sul sistema.

— Gilles 'SO- smetti di essere malvagio' il

2

Sebbene interessante, e ovviamente approvato dall'assistente, non vedo come questa risposta affronti la domanda. Sembra più spiegare perché si potrebbe usare chown -hcome misura cautelativa quando si cambia la proprietà di un file che non dovrebbe essere un collegamento simbolico, ma che potrebbe essere comunque (un caso limite, IMO). Non spiega perché si potrebbe desiderare di cambiare la proprietà di un file che in realtà è destinato a essere un collegamento simbolico, che è ciò che la domanda ha posto.

— Ivan X

Perché chowncambiare il proprietario di "un file fuori dall'albero" è tutto ciò che stai cambiando è il proprietario della directory?

— Melab,

@Melab Quando si modifica il proprietario di un albero di directory , ovvero si annulla l'utilità chown -R, che chiama la (l)chownchiamata di sistema su ciascuna voce di directory. Se la voce della directory è un collegamento simbolico, non è necessario chiamare la chiamata di chownsistema perché influirebbe sulla destinazione del collegamento che potrebbe trovarsi all'esterno dell'albero.

— Gilles 'SO- smetti di essere malvagio' il

8

Apache può essere configurato per seguire i collegamenti simbolici solo se il proprietario del collegamento corrisponde al proprietario della destinazione. Questo può aiutare a impedire agli utenti di creare collegamenti per l'accesso Web ai file che non possiedono (ad esempio / etc / passwd).

... quindi supponiamo che tu, come root, volessi che apache seguisse un link per visualizzare un determinato file di log, che era di proprietà di xymon o qualcosa del genere, ma non volevi rilassare la sicurezza di apache consentendogli di seguire i symlink indipendentemente dal proprietario . Quindi potresti voler rendere xymon il proprietario del link simbolico.

— Lars Rohrbach
fonte

1

Ok. So che non è correlato, ma qual è il punto di questo comportamento in Apache? Voglio dire se l'utente è in grado di leggere il file, perché preoccuparsi di leggerlo dall'accesso al web? grazie

— user368507

Bene, non è solo un utente locale che legge il file; se apache può leggerlo, allora potenzialmente tutti possono leggerlo. E se qualche vulnerabilità di Apache consentisse la creazione di un /etc/passwdcollegamento simbolico , allora il cattivo potrebbe avere accesso in lettura a quel file senza avere altri accessi locali - ma sarebbe vanificato dal collegamento simbolico di proprietà di Apache.

— Lars Rohrbach,

4

La prima risposta non sembra rispondere alla domanda, e la seconda si applica solo ad Apache.

Una cosa che mi viene in mente per Linux in generale è che è possibile per un utente normale creare un collegamento reale a un collegamento simbolico se l'utente è il proprietario del collegamento simbolico. Perché uno vorrebbe fare un tale collegamento, non lo so.

Un'altra cosa è che un utente normale può modificare la proprietà del gruppo di un file solo se l'utente possiede il file (ed è anche un membro del gruppo al quale il file viene aggiunto). Ciò solleva la questione di quale sia la proprietà del gruppo fa un collegamento simbolico. In un'organizzazione, potrebbe essere utile come tag per indicare quale squadra avrebbe bisogno del collegamento.

Inoltre, almeno su Ubuntu, chiunque può aggiornare il timestamp di un collegamento simbolico. Tuttavia, potrebbero esserci alcuni sistemi che consentono solo al proprietario. A che serve il timestamp per un collegamento simbolico, non ne sono sicuro, ma potrebbe fornire alcune informazioni utili su quanto viene utilizzato.

Modifica: ho appena realizzato un altro motivo per cui la proprietà sarebbe importante. Il collegamento potrebbe trovarsi all'interno di una directory adesiva, in cui solo il proprietario di un file può eliminarlo o rinominarlo.

— un altro ragazzo
fonte

0

Ho un programma che si aggiunge a un file di registro. Questi file di registro vengono creati mensilmente ciascuno con un nome diverso. Invece di far capire al software il nome esatto, uso un nome file "generico" (diciamo data.log) che è un collegamento simbolico che punta al file corrente per quel mese. Questo è automatizzato su un lavoro cron.

Ora che viene creato un nuovo file mensile, è necessario puntare il collegamento simbolico al nuovo file. In caso di conflitto di proprietà / gruppo, il software non può modificare il collegamento simbolico. Quindi hai bisogno dei privilegi di scrittura di proprietà / gruppo per cambiare il collegamento simbolico.

— user173610
fonte

0

Se si desidera avere un collegamento a un file nella schermata iniziale, il collegamento simbolico deve trovarsi in

"/ Home / nomeutente / Desktop"

directory.

Inoltre, il collegamento simbolico stesso deve avere la proprietà root: root (0: 0), altrimenti il collegamento non funziona.

(Ubuntu / Debian ecc.)

— Helen Craigman
fonte