Comportamento delle autorizzazioni di collegamento reale diverso tra CentOS 6 e CentOS 7

Ricevo un errore di autorizzazione in CentOS 7 quando provo a creare un collegamento reale. Con le stesse autorizzazioni impostate in CentOS 6 non ottengo l'errore. Il problema è incentrato sulle autorizzazioni di gruppo. Non sono sicuro di quale versione del sistema operativo sia corretta e quale sia errata.

Vorrei illustrare cosa sta succedendo. Nella mia directory di lavoro corrente, ho due directory: sorgente e destinazione. All'inizio, la destinazione è vuota; la fonte contiene un file di testo.

[root@tc-dlx-nba cwd]# ls -l
total 0
drwxrwxrwx. 2 root root  6 Jun 12 14:33 destination
drwxrwxrwx. 2 root root 21 Jun 12 14:33 source
[root@tc-dlx-nba cwd]# ls -l destination/
total 0
[root@tc-dlx-nba cwd]# ls -l source/
total 4
-rw-r--r--. 1 root root 8 Jun 12 14:20 test.txt
[root@tc-dlx-nba cwd]#

Come puoi vedere, per quanto riguarda le autorizzazioni le due directory sono 777, con il proprietario e il gruppo impostati su root. Anche il proprietario e il gruppo del file di testo sono entrambi impostati su root. Tuttavia, le autorizzazioni del file di testo sono di lettura / scrittura per il proprietario ma di sola lettura per il gruppo.

Quando ho effettuato l'accesso come root, non ho problemi a creare un collegamento reale nella directory di destinazione che punta al file di testo (nella directory di origine).

[root@tc-dlx-nba cwd]# ln source/test.txt destination/
[root@tc-dlx-nba cwd]# ls destination/
test.txt

Tuttavia, se accedo come un altro utente, in questo caso, amministratore, non riesco a creare il collegamento. Ottengo: "Operazione non consentita".

[root@tc-dlx-nba cwd]# rm -f destination/test.txt 
[root@tc-dlx-nba cwd]# su admin
bash-4.2$ pwd
/root/cwd
bash-4.2$ ln source/test.txt destination/
ln: failed to create hard link ‘destination/test.txt’ => ‘source/test.txt’: Operation not permitted

Quello che succede in realtà ha senso per me, ma poiché quanto sopra è consentito in CentOS 6, volevo verificare se stavo fraintendendo qualcosa. A me sembra un bug in CentOS 6 che è stato corretto in CentOS 7.

Qualcuno sa cosa dà? Ho ragione nel credere che il comportamento sopra descritto sia il comportamento corretto? CentOS 6 è corretto? Oppure, hanno entrambi ragione e forse c'è qualche sottile problema con le autorizzazioni di gruppo che mi manca? Grazie.

Modifica: ho provato lo stesso test proprio ora su una VM Debian v7 che ho. Debian è d'accordo con CentOS 7: "Operazione non consentita".

Modifica n. 2: ho appena provato la stessa cosa su Mac OS X (Yosemite). Funzionava come CentOS 6. In altre parole, ha permesso di creare il collegamento. (Nota: su OS X, il gruppo radice si chiama "ruota". Questa è l'unica differenza, per quanto ne so.)

centos permissions hard-link

— Mario
fonte

Sembra che l'amministratore dell'utente non disponga delle autorizzazioni per influire sul collegamento. La proprietà del collegamento dipende da chi possiede i file / le cartelle da collegare. L'amministratore non è lo stesso di root. Questi sono i miei 2 centesimi. Come amministratore prova a usare 'sudo ln source / test.txt destination /' Puoi anche iniziare a usare il flag -s. Quando si crea un collegamento senza l'indicatore -s, si crea un collegamento reale. È una ricetta per il disastro perché se il file / la cartella collegati vengono distrutti, lo è anche l'originale. Con i "soft link" di -s la distruzione del file collegato al file non influisce sull'originale.

— Baazigar,

@Baazigar - Grazie. Ci ho pensato. Ecco il mio problema. Ho ereditato un'applicazione Perl che si basa sul comportamento di CentOS 6 (essendo in grado di creare il collegamento). Sto migrando l'applicazione su CentOS 7. Questo è davvero solo un piccolo problema nello schema generale delle cose, ma non so perché viene utilizzata la funzione di collegamento Perl, invece della funzione File :: Copia di Perl. Penso che sarebbe sufficiente copiare il file. Tuttavia, devo fare la mia due diligence prima di cambiare le cose - e non c'è (ovviamente) nessuna documentazione o commenti per spiegare la decisione originale che ho ereditato.

— Mario,

Senza documentazione o giustificazione per come è ora, la soluzione è ugualmente valida supponendo che funzioni e più valida se funziona e dispone di documentazione. Non credo che ci sia stato un cambiamento nella gestione dei collegamenti da parte di centos. Penso che sia più probabile qualcosa che non hai ancora trovato nella vecchia scatola, forse qualcosa nel gruppo / etc / o in qualche altro posto che spieghi l'apparente anomalia.

— Baazigar,

@Baazigar - Ho appena provato la stessa cosa in Mac OS X, anche se ho dovuto usare il gruppo "wheel" (gruppo di root) al posto del gruppo "root". Come forse saprai, OS X è una variante BSD. Funzionava nello stesso modo in cui funzionava CentOS 6, in altre parole, consentiva di creare il collegamento. Non so cosa sia giusto, a questo punto. Non dovrebbe esserci una pratica unificata tra quelli che sono (principalmente) sistemi compatibili con POSIX?

— Mario,

Ho scoperto alcuni nuovi CentOS 6 e 7 vm e sono stato in grado di ricreare il comportamento esatto che hai mostrato. Dopo aver fatto qualche ricerca, si scopre che questo è in realtà un cambiamento nel kernel per quanto riguarda il comportamento predefinito rispetto ai collegamenti hard e soft per motivi di sicurezza. Le seguenti pagine mi hanno indicato la giusta direzione:

http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72bb9c4bfc955edfd415

http://kernel.opensuse.org/cgit/kernel/commit/?id=800179c9b8a1

Se rendi il mondo dei file scrivibile, il tuo utente amministratore sarà in grado di creare il collegamento reale.

Per ripristinare il comportamento del sistema CentOS 6, sono stati aggiunti nuovi parametri del kernel. Impostare quanto segue in /etc/sysctl.conf:

fs.protected_hardlinks = 0
fs.protected_symlinks = 0

quindi corri

sysctl -p

Per quanto riguarda il motivo per cui il tuo programma sceglie di utilizzare i collegamenti invece di copiare i file, perché creare una copia esatta di un file che devi utilizzare quando puoi semplicemente creare una voce che punta ai blocchi originali? Ciò consente di risparmiare spazio su disco e l'operazione è meno costosa in termini di CPU e I / O. Il nuovo hard link è lo stesso file, solo con metadati / inode diversi. Se si dovesse eliminare il file originale dopo aver creato un collegamento reale, ciò non influirà sul collegamento. Un file viene "cancellato" solo dopo aver rimosso tutti i collegamenti.

— Sean
fonte

Grazie. Daremo un'occhiata a questi collegamenti un po 'più tardi oggi. (Avere un voto nel frattempo!) Capisco la differenza tra un hard link e una copia. Il programma che ho ereditato, tuttavia, sta creando un collegamento dal file di origine a un'area di "download" (tramite un front-end di un'applicazione Web). Non penso che lo spazio su disco sia un problema, poiché è solo un file di testo. Inoltre, basandomi sul significato comune di "download", non capisco come si adatti un collegamento: semanticamente, una copia sembrerebbe avere più senso. (Temo che ci sia qualche altro comportamento nel programma che si basa su un collegamento. Dovrò controllare.)

— Mario

"Capisco la differenza tra un collegamento fisico e una copia." Bene, stavo solo scrivendo la mia risposta pensando a un pubblico generale per i futuri utenti che potrebbero non sapere.

— Sean,

Sono tutto per scrivere pensando a un pubblico generale :-) Esaminerò la soluzione migliore per l'applicazione, lunedì. Per fortuna, ho molto margine di manovra. (La mia unica moderazione è "lo rompi; l'hai comprato"!) Segnalo come la risposta accettata. Grazie ancora!

— Mario,

PS Immagino che le persone CentOS abbiano optato per i collegamenti protetti per impostazione predefinita. (Quello che ottengo dai link che hai fornito è che si tratta di un problema controverso.)

— Mario,