Umask est la clef. A demain :)
Pascal -----Original Message----- From: Dubois Vincent <[email protected]> Date: Sun, 06 Dec 2009 21:46:46 To: <[email protected]> Subject: Re: Re : Re: Re : Re: [TECH] chmod + gestion groupe Bon, maintenant le groupe reste, mais ce sont les droits qui passent à 700, d'où toujours aucun accès pour les autres utilisateurs du groupe... Cela se passe notamment quand les fichiers proviennent d'une carte mémoire photo, en vFAT (sans doute liée cette fois aux options de montage?). Mais je vais arrêter de polluer la liste avec ceci, je vais essayer de comprendre ce qu'il se passe avec les explications de Nicolas et celles du site trouvé (http://www.zzee.com/solutions/unix-permissions.shtml#setuid). Bonne soirée, Vincent. [email protected] a écrit : > Oui, bien sur il te faut aussi un g+s, mea culpa de l'avoir omis. Le g+s est > propagé aux nouveaux répertoires donc ca restera dans le futur. > Par contre tu ne peux pas forcer un possesseur autre que le créateur. Il n'y > a pas de système équivalent au setgid du répertoire pour le possesseur. Du > moins pas avec des flags comme utilisés jusqu'à maintenant. > Mais normalement il n'y en a pas besoin, tu peux avoir tous les droits via le > groupe, non ? > > Cordialement, > Pascal > > > -----Original Message----- > From: Dubois Vincent <[email protected]> > Date: Sat, 05 Dec 2009 20:14:55 > To: <[email protected]> > Subject: Re: Re : Re: [TECH] chmod + gestion groupe > > Encore moi... 8-)) > L'option ne fonctionne plus.... :-( > > Trouvé là : http://www.zzee.com/solutions/unix-permissions.shtml#setuid > > In addition to the basic permissions discussed above, there are also > three bits of information defined for files in UNIX: > > * *SUID or setuid: change user ID on execution*. If setuid bit is > set, when the file will be executed by a user, the process will > have the same rights as the owner of the file being executed. > * *SGID or setgid: change group ID on execution*. Same as above, but > inherits rights of the group of the owner of the file. For > directories it also may mean that when a new file is created in > the directory it will inherit the group of the directory (and not > of the user who created the file). > * *Sticky bit*. It was used to trigger process to "stick" in memory > after it is finished, now this usage is obsolete. Currently its > use is system dependant and it is mostly used to suppress deletion > of the files that belong to other users in the folder where you > have "write" access to. > > > J'en conclus que c'est plutôt un chmod -R g+s... > Cela semble fonctionner, le groupe est respecté, à voir dans le temps! > Il ne reste plus qu'à trouver comment faire de même pour le propriétaire > dans les parties pour enfants/invités (le chmod -R u+s / SUID ne faisant > pas vraiment la même chose - je l'ai bien sûr tenté). > > A suivre! > Vincent. > > P.S. : ces options, cela correspond au masque, celui qui peut être > défini dans les options de montage, non? Diffusez cette liste aupres de vos relations :-) Linux Azur : http://linux-azur.org Vous etes responsable de vos propos. *** Pas de message SMS, HTML ni de PJ SVP *** Diffusez cette liste aupres de vos relations :-) Linux Azur : http://linux-azur.org Vous etes responsable de vos propos. *** Pas de message SMS, HTML ni de PJ SVP ***
