Introduzione

Ho visto alcuni disinformazione per quanto riguarda i permessi dei file Unix. Io cercherò di porvi rimedio. Date un'occhiata a questo esempio di uscita da alcuni ls:
Sulla prima riga, che "root", dice che la directory è di proprietà di utente chiamato "root". E che "bin" è il gruppo della directory. Avrete bisogno di capire gli utenti e gruppi e si assume che si fa. Il mio obiettivo è quello di spiegare che "drwxrwxr-x" e "-r-xr-xr-x" roba. Questo campo è una combinazione del tipo di file e le autorizzazioni di accesso. Collettivamente, queste informazioni è a volte chiamato file in modalità. E qualche volta è chiamato il permessi. Un buon punto di partenza è che un rapido sguardo a come queste informazioni sono in realtà memorizzati sul disco. Il modo in cui è memorizzato riguarda una serie di decisioni che sono state fatte nel corso degli anni.

Come "File Mode" è memorizzato.

Il disco, le informazioni su un file viene memorizzato nella struttura denominata "inode". Ogni file avrà una propria inode. Un elemento di dati in un inode è chiamato il "modo", che appare così:
Penso che il "modo" in realtà significa solo i permessi e che il tipo di file è stato messo per risparmiare spazio. Ma l'autore del programma ls trattamento è il modo come un unico elemento. Ecco perché il tipo di file è il primo carattere della stringa di autorizzazione nel "ls-l" uscita. Il tipo di file di solito è uno dei sette tipi di mostrare che ho sopra. Alcune versioni di Unix si aggiungono un paio di più. L'unica altra cosa da notare dai dati di layout è che non c'è spazio per aggiungere altri bit di permessi.

Rappresentare i permessi in ottale

Il ls programma potrebbe visualizzare, ad esempio, "rwxrwxrwx" per le autorizzazioni per un file. È anche molto comune l'utilizzo di un numero ottale di esprimere le autorizzazioni per un file. E come si vede sopra, questo è il modo in cui sono memorizzati. Si può sentire qualcuno dire che circa 777 ha i permessi. Questa è la stessa come "rwxrwxrwx" e molto più facile da pronunciare. Allora avete bisogno di sapere come li converte. Tre cifre binarie o bit corrisponde a una cifra ottale:

Così il "vale la pena di leggere bit 4, la scrittura è un valore di 2 bit e il bit di esecuzione è pari a 1. È sufficiente aggiungere queste fino a ottenere una cifra ottale. Quindi"-rwxrwxrwx "è 777. E"-rwxr-x -- - "è di 750. Se ancora non è possibile vedere come arrivare da" rx "a 5, forse contribuirà a questa tabella:

Nota abbiamo bisogno di 4 cifre ottale di esprimere il consenso di tutti i bit. I primi tre bit sono speciali e sono spesso pari a zero. E quasi sempre è conoscere il trailing 9 bit prima. Alcune persone vi e mai smettere di imparare i primi tre bit. Ma ci sono 12 bit di permessi, non solo 9. Detto questo, diamo ora uno sguardo al traino 9 bit.

Il bit di permessi di base

Abbiamo 3 triple: una tripla per l'utente, una tripla per il gruppo, e una tripla per gli altri. Talvolta il "utente" si chiama il proprietario. E, talvolta, gli "altri" si chiama "mondo". Io uso "utente" e "altri", perché utilizza il comando chmod ug e le lettere o fare riferimento a queste triple.

Set di Bit, che vale anche per lei?

Quando Unix decide cosa si può fare, che non fa uso di tutte le 9 bit. Unix raccoglie la prima tripla che vale anche per lei. Considerate questo: Anche se joe possiede questo file, non può accedervi. (Joe Poiché possiede il file, si potrebbe dare lo stesso accesso. Per saperne di più su questo più tardi.) Anche root è speciale. root è concesso a tutte le directory rwx rw e per tutti i file. Su di un file, se uno qualsiasi dei 3 x bit sono impostati, root ha il permesso in esecuzione. Questo è spesso un permesso speciale per disabili su rete filesystem montati.

Che cosa e rw x davvero significa per un file?

Per un file, "leggere" e "scrivere" sono piuttosto intuitivi. La x per "eseguire" significa che il kernel può tentare di eseguire il file. Per questo al lavoro, il file deve essere un eseguibile (uscita da un compilatore) o uno script di shell con un "#!" prima linea. Per una directory, le cose sono un po 'più complessa. Con una directory, "scrivere" permesso significa che è possibile creare nuovi file nella directory o rimuovere i vecchi file. E a volte le persone sorprese che è possibile rimuovere un file che non puoi leggere. Il comando rm unix si prova per questo problema e un avvertimento, ma si può sopprimere avviso che con-f. E un avvertimento o un no, se si desidera rimuovere un file da un illeggibile directory scrivibile, è possibile. Rmdir e non preoccuparsi di verificare a tutti.

Che cosa e rw x davvero significa per una directory?

Una directory è un file di troppo, e "leggere" permesso significa che puoi leggere. Ma davvero non può fare molto senza permesso x pure. Con la directory, di solito si hanno i permessi di esecuzione e di leggere o non. Su una directory, che x è ufficialmente chiamato "il permesso di ricerca". È necessario utilizzare x una directory in un percorso. Quindi, se si cerca "cat / etc / passwd", sarà necessario x il / e / etc È inoltre necessario x per cd in una directory. Supponiamo di aver letto, ma non di ricerca (x) le autorizzazioni per una directory. Cosa puoi fare? Non molto. È possibile utilizzare "ls" per visualizzare i nomi dei file. Anche "ls-l" non funzionerà. Leggi l'accesso senza il permesso di ricerca non è molto utile. Sempre che sia meglio che avere solo il permesso di scrittura su una directory ... che è completamente inutile. Non ho visto alcuna altra documentazione che afferma esplicitamente, in modo vorrei ripeterlo: scrivere, ma non il permesso in esecuzione su una directory concede nulla al all.Suppose avete ricerca (x) l'autorizzazione, ma non il permesso di leggere in una directory. Ora è possibile aprire i file nella directory, se vi capita di conoscere il nome del file. Puoi cd nella directory. E che è. Non è possibile anche creare un nuovo file. Aggiungere il permesso di scrittura consente di creare file. E poi è possibile eliminare i file, se vi capita di conoscere il loro nome.

Link simbolici sono speciali

Le impostazioni di autorizzazione su un link simbolico sono un po 'speciale come bene. Essi sono completamente ignorati. Molte versioni di Unix non hanno alcuna possibilità di modificarli.

Il setuid setgid e la Bit

Date un'occhiata a questo: Il file passwd è scrivibile solo da root (Ricorda, root è speciale. È possibile scrivere un file che non ha impostato i permessi di scrittura). Il file shadow, che è dove vengono memorizzate le password, non può essere letto anche dai normali utenti. Ma Joe vuole cambiare la propria password. Egli può farlo eseguendo / usr / bin / passwd. Avviso rs quelli permessi. Il programma passwd ha il bit suid e sgid set. Questo trasforma la x in s's. In ottale, sarebbe 6555. Passwd Il programma è di proprietà di root. Quando viene eseguito joe, esso non viene eseguito come "Joe". Invece, che gira come root, che è proprietario. Così il programma passwd può cambiare la password di joe per lui. Il bit sgid funziona allo stesso modo, ad eccezione del fatto che le cause passwd programma da eseguire con il gruppo di sistema, invece di Joe's gruppo. Il suid e sgid non ottenere la loro posizione nel ls. Quando il bit suid impostato, ls mostra come, piuttosto che ax per il proprietario il permesso in esecuzione. Cosa succede se il suid bit è impostato, ma il proprietario è eseguire po 'fuori? ls viene visualizzata una S maiuscola nel caso di specie. Il sgid bit viene visualizzato in maniera simile, tranne per il fatto che interagisce con il gruppo i permessi di esecuzione. (Il concetto è stato fissato uid inventato da Dennis Ritchie come egli è stato in via di sviluppo Unix.)

Per espandere le cose un po ', mentre Joe è in esecuzione il suid-to-root passwd program, "Joe" è il vero e uid "root" è l'efficace uid. Passwd Il programma è in grado di ottenere questi due id se vuole. Questo è come il programma passwd sa joe per consentire di modificare solo la password di joe.

Il Sticky Bit

Il Posix standard dice che se lo sticky bit è impostato su una directory, solo i permessi di scrittura sulla directory non è più sufficiente per consentire i file da rimuovere. È necessario inoltre proprio il file o la directory stessa. principale continua ad essere in grado di eliminare, indipendentemente da qualsiasi directory di autorizzazioni. Precedentemente questo bit servito un altro scopo. Su alcuni sistemi operativi che ancora non. I elaborerà in un allegato di seguito. Il sticky bit riguarda gli "altri" eseguire po 'in ls visualizzare. Tranne per il fatto che usi e T t piuttosto che s e S. Per esempio: In tale directory / tmp sopra, chiunque può creare nuovi file. Ma a causa della sticky bit, un utente non può cancellare i file di un altro utente.

Limitare i permessi dei file con umask

Quando vengono creati i file che crea il programma può specificare l'impostazione iniziale permesso. È possibile ignorare che, con umask. La umask è un insieme di bit che vieta. Ci umask è un comando che consente di visualizzare e modificare l'umask. Ad esempio, "umask 022" vieta gruppo scrivere e scrivere su altri file appena creato. O "umask 027" vieta gruppo scrivere e vieta gli altri leggere, scrivere o eseguire. È possibile fare una "umask 0" a lasciare che il programma di fare ciò che vuole, come si crea programmi. Ma non si può andare oltre. Non si può costringere un programma a sua volta un po 'su. L'impostazione di umask colpisce file, directory, named pipe (FIFO pseudonimo), e file speciali. Si può o non può pregiudicare i collegamenti simbolici. Essa coinvolge anche le forme di Somes Inter processo di comunicazione, ma che è al di là del campo di applicazione del presente articolo. E che ci crediate o meno, che prende il nome prese sono esenti da umask. Tale esenzione è richiesto di Posix.

Cambiare i permessi dei file con chmod

Solo il proprietario di un file o root può cambiare le autorizzazioni per un file. Questa operazione è non a tutti i colpiti dalla umask impostazione. Se si modificano le autorizzazioni per un collegamento simbolico, il link da seguire e si desidera modificare il file di destinazione. E 'possibile che solo root ha il potere di fissare un file di sticky bit. A titolo di esempio, "chmod 700 qualche_file" wil lasciare il proprietario leggere, scrivere ed eseguire il file, mentre tutti rifiutare l'accesso a qualsiasi altri utenti.

Utilizzando la modalità con Symbolic chmod e umask

Posix ha introdotto una nuova sintassi per il comando chmod. L'idea era che la nuova sintassi di sostituire l'uso di un costante ottale con il comando chmod. La costante ottale è ancora permesso e credo che è qui per rimanere. Ma la nuova sintassi simbolico consente di modificare alcune bit senza sapere quello che gli altri sono. Ad esempio, diciamo che voglio fare un file inaccessibili agli altri, ma non quello di cambiare l'accesso per l'utente o il gruppo. Avrei bisogno di fare:
ls-l file
Vedi file e capire le impostazioni correnti.
chmod 750 file
Ho dovuto constatare che le prime due cifre sono correnti di 7 e 5 prima che io possa fare il mio comando chmod. Con la nuova sintassi, posso semplicemente fare:
chmod o \u003d file
per spegnere la finale 3 bit. Come un altro esempio, "chmod u + x file" permette all'utente di eseguire il file. D'altro canto, questi due comandi sono equivalenti:
chmod 750 file
chmod u \u003d rwx, g \u003d rx, o \u003d file
e io preferisco la prima sintassi.

La modalità simbolica può essere una virgola separati elenco di specifiche. Ogni specificazione ha tre componenti: <who> <operation> <bitlist> L'X è lo stesso a meno che il file x è un nondirectory e attualmente non ha alcun x bit set. L's (insieme o insieme uid gid) possono essere specificati solo per l'utente o gruppo di permessi. La t possono essere specificati solo per i permessi utente. Alcuni esempi con l'aiuto. Sopra abbiamo visto / usr / bin / passwd è stato 6555 (-r-sr-sr-x in ls). Ecco alcuni modi in cui potrebbe essere raggiunto:
chmod 6555 / usr / bin / passwd
chmod u \u003d RXS, g \u003d RXS, o \u003d rx / usr / bin / passwd
chmod ug \u003d RXS, o \u003d rx / usr / bin / passwd
chmod a \u003d rx, ug + s / usr / bin / passwd
E ci sono molti altri modi per farlo.

Per la maggior parte chmod è immune da umask in qualunque bit che si vuole impostare non avere modificato dal umask. Tuttavia, a una condizione, il comando chmod esaminerà l'attuale impostazione di umask per determinare quali bit si desidera impostare. Questo succede quando si lascia il "chi" campo vuoto. Come questo:
chmod \u003d w qualche_file
La differenza tra una "w \u003d" e "w \u003d" è sottile. Ecco un esempio che può aiutare. Molti programmi cercano di creare il file con 666 (-rw-rw-rw-) le autorizzazioni. Ma questo viene modificato dal umask. Supponiamo che la si desidera impostare un file di 666, ma modificati dalla umask corrente. Si potrebbe spegnere tutti i bit, quindi svoltare a leggere e scrivere i bit che sono ammessi dalla corrente umask:

chmod a \u003d, \u003d rw qualche_file

E parlando di umask, è possibile utilizzare argomenti simbolico con il comando umask pure. Comunque, Posix, Nella loro saggezza, ha deciso che in questo caso la logica sarebbe invertito. Quindi, se con un uso umask ottale argomento si specifica il bit di essere vietata. Ma se si utilizza umask con un simbolico argomento, si specifica il bit per consentire. Quindi questi sono equivalenti:
umask 022
umask u \u003d rwx, go \u003d rx

Sintesi

A questo punto si dispone di informazioni sufficienti per capire la maggior parte quelli 12 bit di permessi. Ci sono parecchi casi molto particolari che mi hanno ignorato o ignorate. In separata posti al di sotto mi affrontare questi. Le informazioni contenute in questo primo post è molto universale. Un Posix compatibile con sistema operativo deve supportare questa roba. Che copre quasi tutte le versioni di Unix rilasciato negli ultimi 10 anni. I seguenti articoli discutere caratteristiche non può che essere universale.

Ho già detto che quando hanno una directory ha lo sticky bit, di un file può essere eliminato solo dal proprietario del file o il proprietario della directory. Questo comportamento è determinato da Posix e ora invece è universale. Tuttavia questo non era lo scopo originario della sticky bit. Vedo che la Posix definizione del comando ls effettivamente chiede lo sticky bit "la soppressione limitato di bandiera". La costante nel file header di C per questo bit è S_ISVTX. Il svtx sta per salvare il testo e questo rivela il loro scopo originario del bit.

L'idea originale era che, se lo sticky bit è impostato, il segmento di testo di un processo di soggiorno nella zona di swap. Ciò consentirebbe di essere letto in memoria con un letto singolo disco. Originariamente, Unix usato un filesystem con una dimensione di blocco di 512 e la tendenza alla dispersione blocchi. Quindi sarebbe il tempo di raccogliere il segmento di testo e lo carica in memoria. In un primo momento non vi era alcuna radioavviso, solo scambio. E di eseguire un programma avrebbe bisogno di essere completamente caricato in memoria. Ora abbiamo la pagina di default di un programma in memoria. Le pagine vengono caricate in quanto sono necessari. Quindi, è l'originale uso del sticky bit morto? Beh, no. Essa dipende dal sistema operativo.

Con HP-UX, questo utilizzo è ancora vivo e che sia documentato in HP-UX chmod (2) pagina man. Che uso si tratta? Da La HP-UX Kernel Tuning and Performance Guide via HP-UX Faq:
"Quando le domande si trovano in remoto, impostare il" sticky bit "sui binari applicazioni, utilizzando il comando chmod + t. Questo dice al sistema di pagina il testo a disco locale. In caso contrario, è" recuperato "in tutta la rete. Dei Ovviamente, questo dovrebbe essere applicato solo quando non vi è effettiva di paging che si verificano. Più di recente, vi è un parametro del kernel, page_text_to_local, che quando è impostato a 1, dirà al kernel di tutti gli pagina NFS eseguibile pagine di testo a livello locale lo spazio di swap. "

Con Solaris, non vi è alcun segno di originale uso del sticky bit, tuttavia secondo il Solaris chmod (2) pagina man:
"Se un file regolare e non è eseguibile S_ISVTX ha fissato, il file si presume essere un file di swap. In questo caso, il sistema della pagina della cache non sarà utilizzato per contenere il file di dati. Se il S_ISVTX bit è impostato su qualsiasi altro file, i risultati sono non specificato. "

Allora hai bisogno di controllare la chmod (2) pagina man per il vostro sistema operativo per vedere che effetto, se del caso, ha lo sticky bit su un file. Inoltre, essere consapevoli del fatto che se esiste un effetto, il sistema operativo possono limitare la fissazione di un po 'appiccicoso di root. Ad esempio, con HP-UX, un utente malintenzionato potrebbe creare un sacco di sticky bit e il sistema di spazio di swap.

HP-UX effettivamente ha anche alcuni collegamenti simbolici che hanno lo sticky bit impostato. Vorrei affrontare questo qui di seguito.

Abbiamo accennato al fatto che i file che sono un utente e di gruppo ad essi associati. Originariamente, si era appena l'utente e il gruppo di chi li ha creati. Ma inizialmente, un utente potrebbe essere in un solo gruppo alla volta. BSD ha introdotto il concetto che un utente potrebbe essere in più gruppi simutaneously. Quindi, in BSD, gruppo che è stato utilizzato? BSD ha deciso di utilizzare il gruppo della directory che contiene il nuovo file creato.

Molte versioni di Unix moderni cercano di farlo in entrambi i sensi. Il nuovo file viene creato il gruppo degli utenti a meno che la directory ha il bit setgid. In tal caso, il nuovo file viene creato il gruppo della directory.

E vi è una eccezione a questo! Cambiare il proprietario o il gruppo di un file è di sicurezza. Per questo motivo, alcune versioni di Unix sarà, eventualmente, vietare un utente diverso da root di modificare il proprietario di un file. Inoltre, un utente che è vietato modificare il gruppo di un file, se non è un membro del nuovo gruppo. Tale restrizione avrà la setgid bit in una directory se necessario.

Noi non siamo finiti con quella Imposta Gid po 'ancora ... Unix ha un concetto di file di blocco. File di blocco è al di là del campo di applicazione di questo thread. Ma dovete sapere che il blocco di file è disponibile in due sapori: consulenza e manditory. Sapore che si applica ad un file particolare, a seconda delle impostazioni di autorizzazione. Se il gruppo eseguire bit è spento, ma il bit setgid è acceso, si blocca su un qualsiasi file che sono file di manditory.

Inutile Bit combinazione?

Ogni riferimento che ho visto dice che setgid il / gruppo eseguire off è una combinazione altrimenti inutile. Anche Richard Stevens (in Programmazione avanzata in ambiente Unix) Dice: "Dal momento che il set-group-ID bit non ha senso quando il gruppo-bit eseguire è spento, il designer ha scelto di SVR3 questo modo di precisare che il blocco di un file è quello di essere maditory bloccaggio di consulenza e non di chiusura."

Ebbene questo caso, prendere in considerazione: Fred corre il dipartimento Risorse Umane. Fred e il suo gruppo di ricerca hanno spesso bisogno di utilizzare il giorno di vacanza per i lavoratori dipendenti. Fred decide di scrivere un programma di ricerca i dipendenti possono così la propria vacanza giorno utilizzato. Per motivi di sicurezza, Fred rende questo programma fare un sacco di disboscamento. Fred decide che non vuole che il suo gruppo per l'utilizzo di questo programma. Essi hanno altri strumenti che non ingombrare il suo registro. Quindi non Fred:
chown fred: ora vdays
chmod 2701 vdays
Vdays Ora il programma non può essere eseguito dai membri della segreteria (ad eccezione fred). Ma può essere eseguito da tutti gli altri. E si assume la gid di ora quando non funzionare. Ho scritto un programma di test, impostarlo in questo modo, e hanno eseguito su entrambi i Solaris e HP-UX. Funziona.

Effetti sul ls uscita

Sebbene questa combinazione di bit può essere utile è limitata alcuni casi, per una migliore o peggiore, avrà due effetti. Vdays Il programma funziona, ma se un blocco è tentato sul file, sarà manditory. Come una questione pratica, questo sarebbe solo un impatto occasionali programma come un debugger. Ma ls possono trattare questa combinazione po 'diverso. Ho visto questi due ...

Link simbolici sono evolute nel corso degli anni. In un primo tempo, un collegamento simbolico è stata seguita solo quando si apre un file. Quindi:
toccare datafile
ln-s datafile Slink
chmod 700 Slink
non proteggere il file chiamato "datafile". Questo è stato un problema di sicurezza. Oggi che "chmod 700 Slink" cambierà le autorizzazioni per datafile. "chown fred datafile" cambieranno anche datafile e lasciare solo sprofondare.

Link simbolici deve avere un proprietario

C'è un modo per cambiare il proprietario di un collegamento simbolico. E ' "chown-h sprofondare". Questo cambiamento Slink e lasciare solo datafile. L'originale motivo per cui i collegamenti simbolici bisogno di un proprietario è una funzione chiamata "quote". Contingenti permette al sistema di gestione per limitare lo spazio su disco utilizzato da un utente. Un collegamento simbolico consuma una piccola quantità di risorse del disco, quindi deve essere a carico del utente. Abbiamo ora una seconda ragione: appiccicoso directory. Abbiamo bisogno di sapere chi può rimuovere un link simbolico da un appiccicoso directory.

In aggiunta a un proprietario, Posix richiede che hanno un link simbolico dimensioni. Questo è tutto quello che può dipendere. I collegamenti simbolici non può ancora avere il permesso di bit.

Bit di permessi sono tenuti da Posix essere ignorati

Su Solaris e Linux, di recente creazione dei link simbolici sono 777 e questo non è influenzata da umask. Non ho potuto trovare un modo per girare il bit off. Su HP-UX, i collegamenti simbolici sono anche creati con 777, ma umask non interferire con il presente. Quindi:
umask 777
ln-s datafile Slink
crea un collegamento simbolico con tutti i bit si spegne. Questo non ha avuto alcun effetto su quello che a tutti ho potuto fare con datafile. E link simbolico (con una modalità di 0) alle directory anche lavorato bene.

BSD Ha un modo per cambiare il bit di permessi su un link simbolico

I vari BSD tutte le distribuzioni hanno una "chmod-h", che è come la necessaria "chown-h". L'utilizzo di questo comando che ho provato i collegamenti simbolici su FreeBSD e ha rilevato che essi ignorano bit di permessi come bene. Il "chmod-h" comando è attuato mediante un lchmod () chiamata di sistema. (BSD è anche uno lutimes () e una chiamata di sistema "touch-h" per invocarla.) Fin qui, tutto bene. Non c'è niente qui sta violando il Posix standard.

NetBSD Può essere violare la Posix Standard

Secondo il link simbolico NetBSD pagina man: "Il readlink (2) la chiamata di sistema è necessario leggere le autorizzazioni per il collegamento simbolico." readlink () è la chiamata di sistema utilizzati da ls per visualizzare l'obiettivo di un collegamento simbolico. Quindi, con qualcosa come questo: quello datafile è stato ottenuto con readlink (). Non ho l'accesso ad un sistema per il test di NetBSD così non ho potuto verificare questo.

HP-UX Transition Links

Quando riscritto HP HP-UX conformi alla System V Release 4, l'ubicazione dei lotti di file modificati. Come un esempio, il mio preferito spostati da shell / bin / ksh a / usr / bin / ksh. Alcune persone usano ancora / bin / ksh e che il lavoro (per ora) a causa di un link simbolico:
Come viene svolta su HP che sticky bit? Il lchmod () chiamata di sistema è stato preso in prestito da BSD. Questa è una caratteristica privi di documenti di HP-UX. HP L'idea è che si può essere sicuri che un link simbolico adesiva non è stato creato da altri utenti, perché gli utenti non conoscono lchmod. Uso lchmod () per attivare lo sticky bit non cambia le proprietà del collegamento simbolico in alcun modo. L'unica differenza sta nel fatto che HP TL strumenti saranno disposti ad operare sul collegamento simbolico.

Ma qui è ciò che la HP-UX faq ha da dire: "Transizione link sono un po 'più veloce, perché collegata al nome del file è memorizzato nella inode stessa, invece di usare una unità di allocazione per memorizzare il link. "Anche se questa affermazione non è falsa, è terribilmente fuorviante. HP-UX semplicemente veloce supporta i collegamenti simbolici. Se il nome del file di riferimento è abbastanza breve, è memorizzata direttamente nel inode. La transizione avverrà collegamenti ad essere abbastanza breve. Ho visto alcune persone usano lchmod () per attivare lo sticky bit di un link simbolico in uno sforzo per accelerare le cose. Non funziona così.

Transizione collegamenti iniziano a scomparire. Persone che non hanno cambiato da / bin / ksh a / usr / bin / ksh un giorno avere un brusco sorpresa. Di seguito sono riportati alcuni link per il sito web HP.

Il mantenimento di transizione Links
Transizione Collegamenti Comandi (Deprecato)
Collegamenti transizione (Deprecato)

Abbiamo discusso di come i permessi di scrittura controlla la capacità di modificare i dati in un file. Ma come su come modificare il bit di permessi, il proprietario, il gruppo, e anche il timestamp? Nessuno può cambiare nulla su un CD e un NFS server è in grado di annullare uno NFS cliente. Nel successivo dibattito, vorrei assumere un locale filesystem in lettura-scrittura e che l'utente chiamato "root" è opportuno speciali privilegi amministrativi per il file system in questione.

chmod - Cambiare i permessi dei file

Per cambiare i permessi dei file a tutti, è necessario essere il proprietario del file o se deve essere l'utente root. L'utente root può cambiare qualsiasi permesso bit. Questo può non essere vero per il proprietario. L'uno po 'che il proprietario non può essere in grado di accendere la SGID bit.

Per attivare il bit che, il proprietario deve essere membro di un gruppo che il file si trova Se questa restrizione non è stata in vigore, un utente potrebbe semplicemente creare un programma SGID a dare se stesso l'accesso ai file controllato da gruppi diversi da quelli di cui egli appartiene. Ricorda che, come abbiamo accennato in precedenza, la SGID bit è stato spesso in sovraccarico anche essere usato per il file di blocco. Una versione di Unix possono o non possono consentire un file proprietario di accendere il SGID bit di un file in un gruppo diverso, se non eseguire bit è impostato.

Semplicemente girando su un po 'l'esecuzione può comportare la SUID e SGID bit essere eliminato (anche per root). Questo è un elemento di sicurezza per garantire che l'utente intende per il SUID e SGID bit da impostare. L'utente può passare nuovamente esplicitamente. Oppure l'utente può semplicemente impostare esplicitamente tutti i bit in una volta. Anche essere consapevoli del fatto che la scrittura di un file può, su alcune versioni di Unix, chiaro il bit SUID e SGID. Vedi sotto per l'effetto di cambiare il proprietario o il gruppo di un file.

chown - Cambiare il proprietario del file

Originariamente, Unix proprietario di un file per dare via un file. Un file proprietario potrebbe cambiare il proprietario di qualcun altro. Non c'è stato modo per un utente non root per annullare questa operazione. Quando Unix suddiviso in Berkeley / AT & T versioni, l'USG (Unix Support Group, parte di AT & T), le versioni di Unix tendevano ad ereditare questo comportamento. Nel frattempo, BSD (Berkeley Software Distribution, una parte della University of California, Berkeley) chown rimosso da utenti non-root. BSD aveva attuato le quote disco che potrebbero limitare la quantità di spazio su disco di un utente potrebbe avere in un filesystem. Naughty utenti potrebbe dare via di file di grandi dimensioni a Sneek passato contingenti.

Oggi, non è facile dire se un utente non-root può chown un file. Molte versioni di Unix consentire entrambi comportamenti. HP-UX ha un setprivgroup impianto in grado di controllare o meno i membri di un gruppo particolare può invocare chown. Solaris è un Parametro rstchown che può essere impostato per consentire globale chown. L'impostazione di questo parametro disabilita anche un cambiamento del gruppo limitazione descritte di seguito (senza che ciò influisca sulla SGID limitazioni descritte sopra). Recenti hanno una versione per Linux CAP_CHOWN capacità di controllo di questa funzione. Lei avrà bisogno di consultare la documentazione per le altre versioni di Unix. E hai bisogno di consultare il proprio amministratore di sistema per vedere come il vostro sistema è configurato.

Il valore di default con la maggior parte dei sistemi operativi per chown ad essere limitato al solo utente root. E vi è un consenso sul fatto che esso dovrebbe rimanere in questo modo per considerazioni di sicurezza. Se un utente non root non cambiare il proprietario di un file e ogni bit è in esecuzione, il bit di SUID e SGID deve essere cancellata. Questo può o non può succedere con la radice.

chown, chgrp - Cambiare Il file del gruppo

Il comando chown può (con ogni moderna, Posix compatibile con la versione di Unix), anche un gruppo tentativo cambiamento. E vi è un comando chgrp. Entrambi questi invocare il chown () chiamata di sistema per modificare un gruppo. Il fatto che una comune chiamata di sistema è coinvolto aiuta a spiegare perché alcuni OS versioni congiuntamente o applicare le restrizioni relative agli utenti non-root per entrambi proprietario e il gruppo cambia.

Un utente non root può cambiare il gruppo di file di sua proprietà ad un gruppo di cui è membro. Posix vieta a un utente non root dalla modifica di un file di gruppo di un gruppo di cui egli non è un membro. Ma alcuni SO ascensore questa restrizione se la restrizione contro la modifica di un file proprietario è stato revocato.

Se il gruppo è stato modificato da un utente non root ed eseguire uno o bit sono impostati, il bit di SUID e SGID sono liquidati.

tocco - Cambiare il file Timestamp

Quando il contatto di comando è usato per cambiare il timestamp di un file esistente, si invoca il vecchio utime () o la nuova utimes () chiamata di sistema. Per cambiare il timestamp su un file esistente, è necessario proprio il file o essere root. Inoltre, è necessario avere i permessi di scrittura sul file o essere root.