chown : changing ownership - operation not permitted
5 réponses
poulacou
Je suis surpris qu'avec un login utilisateur de ne pouvoir effectuer
un changement de propri=E9taire de fichier.
Je m'explique :
- le type de syst=E8me de fichier est de ext3
$> mount
/dev/sda1 on / type ext3 (rw)
$> cd /tmp
$> touch toto
$> chown fabrice toto
chown: changing ownership of `toto': Operation not permitted
Si je suis en root : aucun soucis, la commande chown r=E9ussi
autre remarque :
- sur une partition NFS, ce chown avec login utilisateur est
possible
j'ai bien essay=E9 de rajout=E9 des options de montage de partition a ext3
mais rien ni fait, je peux toujours pas changer le proprietaire de son
propre fichier avec un login utilisateur sur une partition ext3 (je
croie que c'est identique avec du reiserfs)
Si certain on des remarques a ce sujet ou un solution ...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Luc.Habert.00__arjf
poulacou :
Je suis surpris qu'avec un login utilisateur de ne pouvoir effectuer un changement de propriétaire de fichier.
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettrait trivialement de passer root en donnant un bit s à un programme à toi, puis en le chownant vers root.
autre remarque : - sur une partition NFS, ce chown avec login utilisateur est possible
C'est pas normal. Quels sont les OS du serveur et du client, et les options de montage et d'exportation?
poulacou :
Je suis surpris qu'avec un login utilisateur de ne pouvoir effectuer
un changement de propriétaire de fichier.
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettrait
trivialement de passer root en donnant un bit s à un programme à toi, puis
en le chownant vers root.
autre remarque :
- sur une partition NFS, ce chown avec login utilisateur est
possible
C'est pas normal. Quels sont les OS du serveur et du client, et les options
de montage et d'exportation?
Je suis surpris qu'avec un login utilisateur de ne pouvoir effectuer un changement de propriétaire de fichier.
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettrait trivialement de passer root en donnant un bit s à un programme à toi, puis en le chownant vers root.
autre remarque : - sur une partition NFS, ce chown avec login utilisateur est possible
C'est pas normal. Quels sont les OS du serveur et du client, et les options de montage et d'exportation?
Nicolas George
Luc Habert wrote in message <fahh8b$5fq$:
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettrait trivialement de passer root en donnant un bit s à un programme à toi, puis en le chownant vers root.
If the specified file is a regular file, one or more of the S_IXUSR, S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID (S_ISGID) bits of the file mode shall be cleared upon successful return from chown().
Luc Habert wrote in message <fahh8b$5fq$1@nef.ens.fr>:
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettrait
trivialement de passer root en donnant un bit s à un programme à toi, puis
en le chownant vers root.
If the specified file is a regular file, one or more of the S_IXUSR,
S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not
have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID
(S_ISGID) bits of the file mode shall be cleared upon successful return
from chown().
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettrait trivialement de passer root en donnant un bit s à un programme à toi, puis en le chownant vers root.
If the specified file is a regular file, one or more of the S_IXUSR, S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID (S_ISGID) bits of the file mode shall be cleared upon successful return from chown().
Pascal Bourguignon
poulacou writes:
Je suis surpris qu'avec un login utilisateur de ne pouvoir effectuer un changement de propriétaire de fichier.
Je m'explique : - le type de système de fichier est de ext3 $> mount /dev/sda1 on / type ext3 (rw) $> cd /tmp $> touch toto $> chown fabrice toto chown: changing ownership of `toto': Operation not permitted
C'est normal. Quand on a un système multi-utilisateurs, on a souvent des quotas, ce qui interdit à un utilisateur d'occuper tout l'espace disque. Si les utilisateurs avaient le droit de changer le propriétaire de leurs fichiers, ce serait trop facile de télécharger des tonnes de .avi, et de les "filer" aux petits copains pour faire comme si on n'utilisait pas 600 GB de disque...
Si je suis en root : aucun soucis, la commande chown réussi
autre remarque : - sur une partition NFS, ce chown avec login utilisateur est possible
Ça dépend des options NFS.
j'ai bien essayé de rajouté des options de montage de partition a ext3 mais rien ni fait, je peux toujours pas changer le proprietaire de son propre fichier avec un login utilisateur sur une partition ext3 (je croie que c'est identique avec du reiserfs)
Si certain on des remarques a ce sujet ou un solution ...
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
poulacou <poulacou@gmail.com> writes:
Je suis surpris qu'avec un login utilisateur de ne pouvoir effectuer
un changement de propriétaire de fichier.
Je m'explique :
- le type de système de fichier est de ext3
$> mount
/dev/sda1 on / type ext3 (rw)
$> cd /tmp
$> touch toto
$> chown fabrice toto
chown: changing ownership of `toto': Operation not permitted
C'est normal. Quand on a un système multi-utilisateurs, on a souvent
des quotas, ce qui interdit à un utilisateur d'occuper tout l'espace
disque. Si les utilisateurs avaient le droit de changer le
propriétaire de leurs fichiers, ce serait trop facile de télécharger
des tonnes de .avi, et de les "filer" aux petits copains pour faire
comme si on n'utilisait pas 600 GB de disque...
Si je suis en root : aucun soucis, la commande chown réussi
autre remarque :
- sur une partition NFS, ce chown avec login utilisateur est
possible
Ça dépend des options NFS.
j'ai bien essayé de rajouté des options de montage de partition a ext3
mais rien ni fait, je peux toujours pas changer le proprietaire de son
propre fichier avec un login utilisateur sur une partition ext3 (je
croie que c'est identique avec du reiserfs)
Si certain on des remarques a ce sujet ou un solution ...
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Je suis surpris qu'avec un login utilisateur de ne pouvoir effectuer un changement de propriétaire de fichier.
Je m'explique : - le type de système de fichier est de ext3 $> mount /dev/sda1 on / type ext3 (rw) $> cd /tmp $> touch toto $> chown fabrice toto chown: changing ownership of `toto': Operation not permitted
C'est normal. Quand on a un système multi-utilisateurs, on a souvent des quotas, ce qui interdit à un utilisateur d'occuper tout l'espace disque. Si les utilisateurs avaient le droit de changer le propriétaire de leurs fichiers, ce serait trop facile de télécharger des tonnes de .avi, et de les "filer" aux petits copains pour faire comme si on n'utilisait pas 600 GB de disque...
Si je suis en root : aucun soucis, la commande chown réussi
autre remarque : - sur une partition NFS, ce chown avec login utilisateur est possible
Ça dépend des options NFS.
j'ai bien essayé de rajouté des options de montage de partition a ext3 mais rien ni fait, je peux toujours pas changer le proprietaire de son propre fichier avec un login utilisateur sur une partition ext3 (je croie que c'est identique avec du reiserfs)
Si certain on des remarques a ce sujet ou un solution ...
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
poulacou
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettra it trivialement de passer root en donnant un bit s à un programme à toi, puis en le chownant vers root.
Je comprend toutes ces raisons de sécurité et je les avait en-tête
autre remarque : - sur une partition NFS, ce chown avec login utilisateur est possible
C'est pas normal. Quels sont les OS du serveur et du client, et les optio ns de montage et d'exportation?
mon os du Linux, celui du serveur...impossbile à savoir
sur le net j'ai trouvé des infos par rapport au kernel et à la variable _POSIX_CHOWN_RESTRICTED mais pas évident à modifier à part sous Solaris ca depend aussi du filesytem puisque l'operation est permise sur du cxfs (j'ai testé avec le même os)
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettra it
trivialement de passer root en donnant un bit s à un programme à toi, puis
en le chownant vers root.
Je comprend toutes ces raisons de sécurité et je les avait en-tête
autre remarque :
- sur une partition NFS, ce chown avec login utilisateur est
possible
C'est pas normal. Quels sont les OS du serveur et du client, et les optio ns
de montage et d'exportation?
mon os du Linux, celui du serveur...impossbile à savoir
sur le net j'ai trouvé des infos par rapport au kernel et à la
variable _POSIX_CHOWN_RESTRICTED mais pas évident à modifier à part
sous Solaris
ca depend aussi du filesytem puisque l'operation est permise sur du
cxfs (j'ai testé avec le même os)
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettra it trivialement de passer root en donnant un bit s à un programme à toi, puis en le chownant vers root.
Je comprend toutes ces raisons de sécurité et je les avait en-tête
autre remarque : - sur une partition NFS, ce chown avec login utilisateur est possible
C'est pas normal. Quels sont les OS du serveur et du client, et les optio ns de montage et d'exportation?
mon os du Linux, celui du serveur...impossbile à savoir
sur le net j'ai trouvé des infos par rapport au kernel et à la variable _POSIX_CHOWN_RESTRICTED mais pas évident à modifier à part sous Solaris ca depend aussi du filesytem puisque l'operation est permise sur du cxfs (j'ai testé avec le même os)
Vincent Lefevre
Dans l'article <46cc4919$0$414$, Nicolas George <nicolas$ écrit:
Luc Habert wrote in message <fahh8b$5fq$:
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettrait trivialement de passer root en donnant un bit s à un programme à toi, puis en le chownant vers root.
If the specified file is a regular file, one or more of the S_IXUSR, S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID (S_ISGID) bits of the file mode shall be cleared upon successful return from chown().
C'est la théorie. J'ai vu un NAS où on pouvait prendre l'identité de quelqu'un d'autre via un chown sur programme setuid.
Dans l'article <46cc4919$0$414$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> écrit:
Luc Habert wrote in message <fahh8b$5fq$1@nef.ens.fr>:
C'est normal, pour tout un tas de raisons. Par exemple, ça te
permettrait trivialement de passer root en donnant un bit s à un
programme à toi, puis en le chownant vers root.
If the specified file is a regular file, one or more of the
S_IXUSR, S_IXGRP, or S_IXOTH bits of the file mode are set, and
the process does not have appropriate privileges, the
set-user-ID (S_ISUID) and set-group-ID (S_ISGID) bits of the
file mode shall be cleared upon successful return from chown().
C'est la théorie. J'ai vu un NAS où on pouvait prendre l'identité
de quelqu'un d'autre via un chown sur programme setuid.
Dans l'article <46cc4919$0$414$, Nicolas George <nicolas$ écrit:
Luc Habert wrote in message <fahh8b$5fq$:
C'est normal, pour tout un tas de raisons. Par exemple, ça te permettrait trivialement de passer root en donnant un bit s à un programme à toi, puis en le chownant vers root.
If the specified file is a regular file, one or more of the S_IXUSR, S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID (S_ISGID) bits of the file mode shall be cleared upon successful return from chown().
C'est la théorie. J'ai vu un NAS où on pouvait prendre l'identité de quelqu'un d'autre via un chown sur programme setuid.
