Semble que chown est autorisé à l'user non root

Nous utilisons l'authentification LDAP et probablement une autre chose que je n'ai pas bien compris, dans notre entreprise, peut-être que les questions suivantes en découlent. J'ai trouvé un comportement étrange de command chown , et je ne sais pas si c'est normal. Voici mon scénario:

GID de la marque de l'user est SK001936 et le propriétaire grup de la maison dir de marque est SK001778, comme vous pouvez le voir, ils ne sont pas les mêmes. Le groupe SK001778 est autorisé à toutes les opérations (rwx) avec le directory d'accueil de la marque de l'user comme propriétaire (marque) a:

 [mark@machine ~]$ id uid=48447(mark) gid=41795(SK001936) groups=40119(SUB_SK001936_PPS),41795(SK001936) [mark@machine ~]$ ls -lad . drwxrwxr-x 6 mark SK001778 4096 Oct 10 13:30 . 

GID de l'user michael et mark sont tous les deux SK001936:

 [michael@machine mark]$ id uid=40570(michael) gid=41795(SK001936) groups=40119(SUB_SK001936_PPS),41795(SK001936) [mark@machine ~]$ id uid=48447(mark) gid=41795(SK001936) groups=40119(SUB_SK001936_PPS),41795(SK001936) 

l'user michael ne peut pas créer de file dans le directory home de la marque de l'user. C'est le fait que michael n'appartient pas au groupe (SK001778) qui a l'access complet (rwx) au directory personnel de mark:

 [michael@machine mark]$ touch michael touch: cannot touch `michael': Permission denied 

Dans des circonstances normales, l'user ne peut pas émettre le chown même s'il est le propriétaire du file. Cependant, dans cet exemple, le propriétaire du directory de base (mark) peut changer le groupe propriétaire de son propre directory personnel (et permet ainsi aux users appartenant à ce groupe d'accéder à son directory local):

 [mark@machine ~]$ chown mark:SK001936 . 

Le groupe qui a maintenant access à mark home dir est donc le même groupe que GID de michael, d'où le michael est maintenant autorisé à créer / supprimer des files / dossiers dans le directory home de mark:

 [michael@machine mark]$ touch michael 

mark ne peut pas changer la propriété du groupe de son directory local (souvenez-vous que la racine est autorisée à émettre un chown accoring à ceci:

 [mark@machine ~]$ chown mark:SK001778 . chown: changing ownership of `.': Operation not permitted 

Ma question est la suivante: comment cette marque a-t-elle pu changer la propriété du groupe de son home dir même si elle a déclaré que chown ne peut être délivré que par root. La boîte est RedHat 5.6.

Lorsque vous utilisez chown d'une manière qui ne modifie que le groupe, alors il agit de la même façon que chgrp . Le propriétaire d'un file ou d'un directory peut changer le groupe en un groupe dont il est membre.

Cela fonctionne comme ça parce que les commands chown et chgrp utilisent toutes deux le même chown sous-jacent syscall, ce qui permet de changer de propriétaire et de groupe. Le syscall est ce qui applique le contrôle d'autorisation. La seule différence entre les commands chown et chgrp est la syntaxe que vous utilisez pour spécifier la modification que vous voulez faire.

Mark ne peut pas changer le groupe à SK001778 car il n'est pas membre du groupe SK001778 (et il n'est pas root, ce qui n'est pas limité par l'appartenance à un groupe).

Les users peuvent l'utiliser pour changer de groupe, en supposant qu'ils appartiennent à l'un de ces groupes.

Exemple

Dire que je suis dans les groupes suivants:

 $ groups saml vboxusers jupiter newgrp 

Et j'ai un file:

 $ ls -l | grep afile -rw-rw-r-- 1 saml saml 0 Oct 10 11:29 afile 

donc je change le groupe de ce file comme ceci: L

 $ chown saml.newgrp afile $ ls -l | grep afile -rw-rw-r-- 1 saml newgrp 0 Oct 10 11:29 afile 

Vous pouvez également utiliser chown comme ceci:

 $ chown .saml afile $ ls -l|grep afile -rw-rw-r-- 1 saml saml 0 Oct 10 11:29 afile