Sign in to follow this  
daniele

GESTIONE UTENZE, Privilegi e BOOT

Recommended Posts

Guest

E si pianta li! Riassumo. Ho smanettato con la login del macosx 10.3 su un ibook 900, cambiando la proprieta per cui veniva fatto l'autologin, senza riavviare ho dato un occhio agli aggiornamenti e ho trovato un aggiornamento che mi mancava (07/09/2004). Scaricato e istallato l'aggiornamento dopo il reboot non mi visualizza piu la finestra di login. Ho provato con il CD di panther a reimpostare le pwd dei vari utenti ma ancora nada. Che cacchio e' successo? Vi e' mai capitato? e se si come si risolve?

Share this post


Link to post
Share on other sites
Guest

Scusa, ma non ho capito niente. <FONT COLOR="ff0000">Ho smanettato con la login del macosx 10.3 su un ibook 900, cambiando la proprieta per cui veniva fatto l'autologin...</FONT> Cosa vul dire? <FONT COLOR="ff0000">dopo il reboot non mi visualizza piu la finestra di login. </FONT> Ma non avevi impostato l'auto-login?

Share this post


Link to post
Share on other sites
Guest

L'ultima volta che ho riparato i privilegi del disco di avvio di OS X 10.3.4 mi è apparso un messaggio per me poco comprensibile, ossia:

<FONT COLOR="aa00aa">Permissions differ on ./System/Library/Filesystems/cd9660.fs/cd9660.util,

should be -rwxr-xr-x , they are -rwsr-xr-x</FONT>

Come "they are -rwsr-xr-x ???

Cosa significa quella "s" che ho segnalato in neretto?

Io ero rimasto che i permessi potevano essere "r", "w", "x". Il significato del permesso "s" mi sfugge...

Vuole dire qualcosa, oppure il mio computer si è ubriacato?

Share this post


Link to post
Share on other sites

Evidentemente per quel cavolo di file non ci si puo' far niente:

http://docs.info.apple.com/article.html?artnum=107298

Comunque per cosa sia il permesso s questo e' quanto viene dal man della Redhat che ho sotto mano ma dovrebbe andar bene uguale:

The letters ‘rwxXstugo’ select the new permissions for the affected users: read (r), write (w), execute (or access for directories) (x),execute only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), sticky (t), the permissions granted to the user who owns the file (u), the permissions granted to other users who are members of the file’s group (g), and the permissions granted to users that are in neither of the two preceding categories (o).

Share this post


Link to post
Share on other sites

Sì, s è il bit setuid (o setgid, a seconda della posizione). setuid vuol dire che, quando il file viene eseguito, l'utente effettivo viene impostato al proprietario del file; setgid imposta il gruppo alla gruppo del file. In pratica, si usa per far salire automaticamente i privilegi di alcuni programmi, indipendentemente da chi li esegue.

Siccome i bit setuid e setgid hanno senso solo per i file eseguibili, nella rappresentazione a lettere vengono indicati da una s al posto della x (nella parte owner per setuid, nella parte group per setgid); è sottinteso che anche la x è presente.

Per quanto riguarda il messaggio di Disk Utility, nel caso di Mirko è corretto. Quel file non dovrebbe avere il bit setuid attivo, e la riparazione dei privilegi corregge il problema.

Nel caso del messaggio di Gianmarco, si tratta di un bug benigno. Il messaggio dice: <FONT COLOR="0000ff">"We are using special permissions for the file or directory ./System/Library/Filesystems/cd9660.fs/cd9660.util.

New permissions are 33261"</FONT>

ANTONACCI STYLE:

Posted Image

Le prime due cifre del numero ottale indicano il tipo di file, la terza i modi speciali (setuid, setgid, sticky), la quarta i permessi del proprietario, la quinta del gruppo, la sesta degli altri. Il valore 100755 indica un file ordinario con permessi -rwxr-xr-x: non c'è nulla di speciale, e quando capita di vedere quel messaggio, i permessi di solito sono già corretti. Infatti il messaggio si ripresenta ad ogni esecuzione della riparazione permessi.

Probabilmente, questo è quello che accade: quando legge il disco, Disk Utility prende le ultime quattro cifre (0755), perché il tipo di file non interessa; nel suo database, però, per il file cd9660.util ha indicato il valore 100755: DU vede che numeri sono diversi, mostra il messaggio e modifica i modi a 100755, cioè il valore che avevano già. Ripetere a piacere.

Share this post


Link to post
Share on other sites
Guest

Ottimo, Camillo.

Fino alla rappresentazione ottale di 33261, c'ero arrivato da solo, pero' mi chiedevo come si decifrano i valori delle prime tre cifre (100755). Mi dai un aiutino? Grazie.

Visto che in certe occasioni puo' servire, io aggiungerei anche: <FONT COLOR="808080">Siccome i bit setuid e setgid hanno senso solo per i file eseguibili</FONT> e le directory [...] Perlomeno, a me serve qualche volta impostare il setgid su di una directory per risolvere problemi di condivisione files tra utenti diversi.

Share this post


Link to post
Share on other sites

Mirko: <FONT COLOR="ff0000">Complimenti Camillo.</FONT>

Michele: <FONT COLOR="ff6000">Ottimo, Camillo.</FONT>

Grazie, ma produco solo gossip.

Michele: <FONT COLOR="ff6000">pero' mi chiedevo come si decifrano i valori delle prime tre cifre (100755). Mi dai un aiutino? Grazie.</FONT>

Le prime due cifre, come dicevo sopra, indicano il tipo di file. In realtà non è proprio così: il tipo è indicato dal bit meno significativo della prima, e da tutti e tre i bit della seconda. Mascherando i bit utilizzati si ottiene un numero ottale a due cifre che va da 00 a 17.

Nella man page di stat sono indicate le costanti corrispondenti a questi bit:

<FONT COLOR="0000ff"> #define S_IFMT 0170000 /* type of file */

#define S_IFIFO 0010000 /* named pipe (fifo) */

#define S_IFCHR 0020000 /* character special */

#define S_IFDIR 0040000 /* directory */

#define S_IFBLK 0060000 /* block special */

#define S_IFREG 0100000 /* regular */

#define S_IFLNK 0120000 /* symbolic link */

#define S_IFSOCK 0140000 /* socket */

#define S_IFWHT 0160000 /* whiteout */</FONT>

S_IFMT è la maschera dei bit che indicano il tipo, le altre costanti sono i valori attualmente definiti. Da notare che gli specifici valori di queste costanti non sono definiti dalla specifica Posix, anche se di fatto dovrebbero essere identici in tutte le varianti di Unix.

La terza cifra contiene alcuni bit speciali:

<FONT COLOR="0000ff"> #define S_ISUID 0004000 /* set user id on execution */

#define S_ISGID 0002000 /* set group id on execution */

#define S_ISVTX 0001000 /* save swapped text even after use */</FONT>

S_ISUID e S_ISGID li conosci già. S_ISVTX è più noto come "sticky bit". Sui file, di fatto non è più usato; sulle directory serve a limitare la possibilità di cancellare file. Normalmente, chiunque abbia accesso in scrittura ad una directory può aggiungere e rimuovere file; se lo sticky bit della directory è attivo, solo il proprietario della directory, il proprietario del file, o il superuser possono cancellare i file. Questo permette di avere delle cartelle in cui tutti possono aggiungere file, ma ciascuno può cancellare solo i propri.

<FONT COLOR="ff6000">Visto che in certe occasioni puo' servire, io aggiungerei anche: Siccome i bit setuid e setgid hanno senso solo per i file eseguibili e le directory [...] Perlomeno, a me serve qualche volta impostare il setgid su di una directory per risolvere problemi di condivisione files tra utenti diversi.</FONT>

E' vero: su una directory, S_ISUID fa sì che tutti i file creati al suo interno abbiano come proprietario quello della directory; S_ISGID fa la stessa cosa per il gruppo. Tuttavia questo accade solo se il file system supporta questa funzione, e sembra che non sia questo il caso di HFS+ su OS X 10.3: dalle prove che ho effettuato, l'uid dei file è sempre quello del processo che li crea, e il gid è sempre quello della directory che li contiene, indipendentemente dai bit setuid/setgid.

Share this post


Link to post
Share on other sites
Guest

Grazie di nuovo. Ho fatto una prova veloce lanciando delle touch da terminale, per creare dei file nuovi, da utenti diversi, prima e dopo aver cambiato i permessi della directory contenitore: mi sembra che il setgid funzioni anche su OS X 10.3 e HFS+ (?).

Share this post


Link to post
Share on other sites

Da me setuid e setgid sulle directory non sembrano avere effetto:

Posted Image

Il sistema si comporta come se tutte le directory avessero il bit setuid spento e il setgid acceso, qualunque sia il loro effettivo valore.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this