pourquoi le super-utilisateur root ne peut-il pas manipuler le fichier avec Python ?
Tu dois avoir une protection sur /tmp /usr/local/bin ou /var/tmp sont peut-être plus adaptés. -- Stéphane
pata...
Le jeudi 17 décembre 2020 Í 12:16:06 UTC+1, yamo' a écrit :
Salut, x a tapoté le 17/12/2020 10:56:
pourquoi le super-utilisateur root ne peut-il pas manipuler le fichier avec Python ?
Tu dois avoir une protection sur /tmp /usr/local/bin ou /var/tmp sont peut-être plus adaptés. -- Stéphane
bingo Stéphane ! le "sticky bit" positionné sur /tmp/ empêche l'utilisateur root d'altérer le fichier appartenant au simple utilisateur user ! $ ls -ld /tmp/ drwxrwxrwt 13 root root 320 Dec 17 13:22 /tmp/ $ ls -l /tmp/test -rw-r--r-- 1 user user 0 Dec 17 13:24 /tmp/test $ echo test | sudo tee -a /tmp/test tee: /tmp/test: Permission denied test mais il n'empêche pas sa suppression ! $ sudo rm -v /tmp/test removed '/tmp/test' ce qui m'a induit en erreur : désolé pour la perte de temps. bonne fin d'année 2020, lacsaP.
Le jeudi 17 décembre 2020 Í 12:16:06 UTC+1, yamo' a écrit :
Salut,
x a tapoté le 17/12/2020 10:56:
> pourquoi le super-utilisateur root ne peut-il pas manipuler le fichier avec Python ?
Tu dois avoir une protection sur /tmp
/usr/local/bin ou /var/tmp sont peut-être plus adaptés.
--
Stéphane
bingo Stéphane !
le "sticky bit" positionné sur /tmp/ empêche l'utilisateur root d'altérer le fichier appartenant au simple utilisateur user !
$ ls -ld /tmp/
drwxrwxrwt 13 root root 320 Dec 17 13:22 /tmp/
$ ls -l /tmp/test
-rw-r--r-- 1 user user 0 Dec 17 13:24 /tmp/test
$ echo test | sudo tee -a /tmp/test
tee: /tmp/test: Permission denied
test
mais il n'empêche pas sa suppression !
$ sudo rm -v /tmp/test
removed '/tmp/test'
ce qui m'a induit en erreur : désolé pour la perte de temps.
Le jeudi 17 décembre 2020 Í 12:16:06 UTC+1, yamo' a écrit :
Salut, x a tapoté le 17/12/2020 10:56:
pourquoi le super-utilisateur root ne peut-il pas manipuler le fichier avec Python ?
Tu dois avoir une protection sur /tmp /usr/local/bin ou /var/tmp sont peut-être plus adaptés. -- Stéphane
bingo Stéphane ! le "sticky bit" positionné sur /tmp/ empêche l'utilisateur root d'altérer le fichier appartenant au simple utilisateur user ! $ ls -ld /tmp/ drwxrwxrwt 13 root root 320 Dec 17 13:22 /tmp/ $ ls -l /tmp/test -rw-r--r-- 1 user user 0 Dec 17 13:24 /tmp/test $ echo test | sudo tee -a /tmp/test tee: /tmp/test: Permission denied test mais il n'empêche pas sa suppression ! $ sudo rm -v /tmp/test removed '/tmp/test' ce qui m'a induit en erreur : désolé pour la perte de temps. bonne fin d'année 2020, lacsaP.
Francois Lafont
Hello, On 12/17/20 1:28 PM, wrote:
bingo Stéphane ! le "sticky bit" positionné sur /tmp/ empêche l'utilisateur root d'altérer le fichier appartenant au simple utilisateur user ! $ ls -ld /tmp/ drwxrwxrwt 13 root root 320 Dec 17 13:22 /tmp/ $ ls -l /tmp/test -rw-r--r-- 1 user user 0 Dec 17 13:24 /tmp/test $ echo test | sudo tee -a /tmp/test tee: /tmp/test: Permission denied test mais il n'empêche pas sa suppression ! $ sudo rm -v /tmp/test removed '/tmp/test' ce qui m'a induit en erreur : désolé pour la perte de temps.
Et bien c'est assez curieux quand même (même si pas vraiment de lien avec Python) car personnellement je n'ai pas le même comportement que toi sur ma Ubuntu 18.04 : ----------------------------------------------------------------- # Je suis "flaf" un compte « lambda ». ~$ whoami flaf # Avec sudo, je suis root. ~$ sudo whoami root ~$ ls -ld /tmp/ drwxrwxrwt 21 root root 12288 Dec 17 23:19 /tmp/ ~$ ls -l /tmp/test -rw-r--r-- 1 flaf flaf 8 Dec 17 23:23 /tmp/test ~$ cat /tmp/test aaa bbb # Je n'ai pas d'erreur ici contrairement Í toi. ~$ echo test | sudo tee -a /tmp/test test ~$ cat /tmp/test aaa bbb test ~$ sudo rm -v /tmp/test removed '/tmp/test' ~$ ls -l /tmp/test ls: cannot access '/tmp/test': No such file or directory ----------------------------------------------------------------- Pour moi, sticky bit ou non, root devrait pouvoir écrire et effacer le fichier. Le comportement que je constate sur ma machine me semble normal et, du coup, je ne comprends pas le comportement que tu constates sur ta machine. Donc pour moi, ton souci n'est pas encore éclairci. -- François Lafont
Hello,
On 12/17/20 1:28 PM, pata...@gmail.com wrote:
bingo Stéphane !
le "sticky bit" positionné sur /tmp/ empêche l'utilisateur root d'altérer le fichier appartenant au simple utilisateur user !
$ ls -ld /tmp/
drwxrwxrwt 13 root root 320 Dec 17 13:22 /tmp/
$ ls -l /tmp/test
-rw-r--r-- 1 user user 0 Dec 17 13:24 /tmp/test
$ echo test | sudo tee -a /tmp/test
tee: /tmp/test: Permission denied
test
mais il n'empêche pas sa suppression !
$ sudo rm -v /tmp/test
removed '/tmp/test'
ce qui m'a induit en erreur : désolé pour la perte de temps.
Et bien c'est assez curieux quand même (même si pas vraiment de lien avec Python)
car personnellement je n'ai pas le même comportement que toi sur ma Ubuntu 18.04 :
-----------------------------------------------------------------
# Je suis "flaf" un compte « lambda ».
~$ whoami
flaf
# Avec sudo, je suis root.
~$ sudo whoami
root
~$ ls -ld /tmp/
drwxrwxrwt 21 root root 12288 Dec 17 23:19 /tmp/
~$ ls -l /tmp/test
-rw-r--r-- 1 flaf flaf 8 Dec 17 23:23 /tmp/test
~$ cat /tmp/test
aaa
bbb
# Je n'ai pas d'erreur ici contrairement Í toi.
~$ echo test | sudo tee -a /tmp/test
test
~$ cat /tmp/test
aaa
bbb
test
~$ sudo rm -v /tmp/test
removed '/tmp/test'
~$ ls -l /tmp/test
ls: cannot access '/tmp/test': No such file or directory
-----------------------------------------------------------------
Pour moi, sticky bit ou non, root devrait pouvoir écrire et effacer le
fichier. Le comportement que je constate sur ma machine me semble normal
et, du coup, je ne comprends pas le comportement que tu constates sur ta
machine. Donc pour moi, ton souci n'est pas encore éclairci.
bingo Stéphane ! le "sticky bit" positionné sur /tmp/ empêche l'utilisateur root d'altérer le fichier appartenant au simple utilisateur user ! $ ls -ld /tmp/ drwxrwxrwt 13 root root 320 Dec 17 13:22 /tmp/ $ ls -l /tmp/test -rw-r--r-- 1 user user 0 Dec 17 13:24 /tmp/test $ echo test | sudo tee -a /tmp/test tee: /tmp/test: Permission denied test mais il n'empêche pas sa suppression ! $ sudo rm -v /tmp/test removed '/tmp/test' ce qui m'a induit en erreur : désolé pour la perte de temps.
Et bien c'est assez curieux quand même (même si pas vraiment de lien avec Python) car personnellement je n'ai pas le même comportement que toi sur ma Ubuntu 18.04 : ----------------------------------------------------------------- # Je suis "flaf" un compte « lambda ». ~$ whoami flaf # Avec sudo, je suis root. ~$ sudo whoami root ~$ ls -ld /tmp/ drwxrwxrwt 21 root root 12288 Dec 17 23:19 /tmp/ ~$ ls -l /tmp/test -rw-r--r-- 1 flaf flaf 8 Dec 17 23:23 /tmp/test ~$ cat /tmp/test aaa bbb # Je n'ai pas d'erreur ici contrairement Í toi. ~$ echo test | sudo tee -a /tmp/test test ~$ cat /tmp/test aaa bbb test ~$ sudo rm -v /tmp/test removed '/tmp/test' ~$ ls -l /tmp/test ls: cannot access '/tmp/test': No such file or directory ----------------------------------------------------------------- Pour moi, sticky bit ou non, root devrait pouvoir écrire et effacer le fichier. Le comportement que je constate sur ma machine me semble normal et, du coup, je ne comprends pas le comportement que tu constates sur ta machine. Donc pour moi, ton souci n'est pas encore éclairci. -- François Lafont
Alain Ketterlin
Francois Lafont writes:
le "sticky bit" positionné sur /tmp/ empêche l'utilisateur root d'altérer le fichier appartenant au simple utilisateur user !
car personnellement je n'ai pas le même comportement que toi sur ma Ubuntu 18.04 :
[...]
Pour moi, sticky bit ou non, root devrait pouvoir écrire et effacer le fichier. Le comportement que je constate sur ma machine me semble normal et, du coup, je ne comprends pas le comportement que tu constates sur ta machine. Donc pour moi, ton souci n'est pas encore éclairci.
Tu as parfaitement raison, root peut toujours modifier un fichier, sauf attribut spécifique (cf chattr/lsattr), ce qui ne semble pas être le cas ici. Le comportement initial (une erreur de root) reste inexpliqué. De plus, le sticky bit n'a pas le rÍ´le qu'on lui prête plus haut. Sur un répertoire, le sticky est une restriction : il empêche quiconque n'est ni propriétaire du fichier, ni propriétaire du répertoire, ni root, de supprimer ou renommer le fichier. Ces deux opérations (supprimer/renommer) sont des opérations sur le répertoire (/tmp ici), pas sur le fichier. Comme /tmp est rwxrwxrwx, n'importe qui pourrait effacer les fichiers de n'importe qui (d'autre) sans le sticky bit. Et tout cela n'a rien Í voir avec la capacité de modifier le contenu du fichier. -- Alain.
le "sticky bit" positionné sur /tmp/ empêche l'utilisateur root
d'altérer le fichier appartenant au simple utilisateur user !
car personnellement je n'ai pas le même comportement que toi sur ma
Ubuntu 18.04 :
[...]
Pour moi, sticky bit ou non, root devrait pouvoir écrire et effacer le
fichier. Le comportement que je constate sur ma machine me semble normal
et, du coup, je ne comprends pas le comportement que tu constates sur ta
machine. Donc pour moi, ton souci n'est pas encore éclairci.
Tu as parfaitement raison, root peut toujours modifier un fichier, sauf
attribut spécifique (cf chattr/lsattr), ce qui ne semble pas être le cas
ici. Le comportement initial (une erreur de root) reste inexpliqué.
De plus, le sticky bit n'a pas le rÍ´le qu'on lui prête plus haut. Sur un
répertoire, le sticky est une restriction : il empêche quiconque n'est
ni propriétaire du fichier, ni propriétaire du répertoire, ni root, de
supprimer ou renommer le fichier. Ces deux opérations
(supprimer/renommer) sont des opérations sur le répertoire (/tmp ici),
pas sur le fichier. Comme /tmp est rwxrwxrwx, n'importe qui pourrait
effacer les fichiers de n'importe qui (d'autre) sans le sticky bit. Et
tout cela n'a rien Í voir avec la capacité de modifier le contenu du
fichier.
le "sticky bit" positionné sur /tmp/ empêche l'utilisateur root d'altérer le fichier appartenant au simple utilisateur user !
car personnellement je n'ai pas le même comportement que toi sur ma Ubuntu 18.04 :
[...]
Pour moi, sticky bit ou non, root devrait pouvoir écrire et effacer le fichier. Le comportement que je constate sur ma machine me semble normal et, du coup, je ne comprends pas le comportement que tu constates sur ta machine. Donc pour moi, ton souci n'est pas encore éclairci.
Tu as parfaitement raison, root peut toujours modifier un fichier, sauf attribut spécifique (cf chattr/lsattr), ce qui ne semble pas être le cas ici. Le comportement initial (une erreur de root) reste inexpliqué. De plus, le sticky bit n'a pas le rÍ´le qu'on lui prête plus haut. Sur un répertoire, le sticky est une restriction : il empêche quiconque n'est ni propriétaire du fichier, ni propriétaire du répertoire, ni root, de supprimer ou renommer le fichier. Ces deux opérations (supprimer/renommer) sont des opérations sur le répertoire (/tmp ici), pas sur le fichier. Comme /tmp est rwxrwxrwx, n'importe qui pourrait effacer les fichiers de n'importe qui (d'autre) sans le sticky bit. Et tout cela n'a rien Í voir avec la capacité de modifier le contenu du fichier. -- Alain.
pata...
bonjour, le comportement semble cohérent avec ce qui est annoncé sur Wikipedia : """ When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. """ la seule action possible pour root serait de renommer ou supprimer le fichier. ce qui est le cas pour moi : $ cd /tmp/ $ ./append $ sudo mv test toto $ echo test | sudo tee -a toto tee: toto: Permission non accordée test $ sudo rm toto lacsaP
bonjour,
le comportement semble cohérent avec ce qui est annoncé sur Wikipedia :
"""
When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file.
"""
la seule action possible pour root serait de renommer ou supprimer le fichier.
ce qui est le cas pour moi :
$ cd /tmp/
$ ./append
$ sudo mv test toto
$ echo test | sudo tee -a toto
tee: toto: Permission non accordée
test
$ sudo rm toto
bonjour, le comportement semble cohérent avec ce qui est annoncé sur Wikipedia : """ When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. """ la seule action possible pour root serait de renommer ou supprimer le fichier. ce qui est le cas pour moi : $ cd /tmp/ $ ./append $ sudo mv test toto $ echo test | sudo tee -a toto tee: toto: Permission non accordée test $ sudo rm toto lacsaP
pata...
re, quelques tests supplémentaires. le script python append est modifié avec """ with open('/test/test', 'a'): pass """ pour travailler dans le dossier /test/. $ cd /tmp/ $ sudo mkdir -m 777 /test $ ./append $ ls -ld /test/ drwxrwxrwx 2 root root 4096 18 déc. 15:12 /test/ $ ls -l /test/ total 0 -rw-r--r-- 1 user user 0 18 déc. 15:12 test $ sudo ./append $ # pas de problème ici $ sudo chmod +t /test/ $ ls -ld /test/ drwxrwxrwt 2 root root 4096 18 déc. 15:12 /test/ $ ./append $ sudo ./append Traceback (most recent call last): File "/tmp/./append", line 2, in <module> with open('/test/test', 'a'): pass PermissionError: [Errno 13] Permission denied: '/test/test' $ sudo rm /test/test je pensais qu'éventuellement cela pouvait venir du fait que /tmp/ est monté en tmpfs, mais non car le dossier /test/ a le même comportement.
re,
quelques tests supplémentaires.
le script python append est modifié avec """ with open('/test/test', 'a'): pass """ pour travailler dans le dossier /test/.
$ cd /tmp/
$ sudo mkdir -m 777 /test
$ ./append
$ ls -ld /test/
drwxrwxrwx 2 root root 4096 18 déc. 15:12 /test/
$ ls -l /test/
total 0
-rw-r--r-- 1 user user 0 18 déc. 15:12 test
$ sudo ./append
$ # pas de problème ici
$ sudo chmod +t /test/
$ ls -ld /test/
drwxrwxrwt 2 root root 4096 18 déc. 15:12 /test/
$ ./append
$ sudo ./append
Traceback (most recent call last):
File "/tmp/./append", line 2, in <module>
with open('/test/test', 'a'): pass
PermissionError: [Errno 13] Permission denied: '/test/test'
$ sudo rm /test/test
je pensais qu'éventuellement cela pouvait venir du fait que /tmp/ est monté en tmpfs, mais non car le dossier /test/ a le même comportement.
re, quelques tests supplémentaires. le script python append est modifié avec """ with open('/test/test', 'a'): pass """ pour travailler dans le dossier /test/. $ cd /tmp/ $ sudo mkdir -m 777 /test $ ./append $ ls -ld /test/ drwxrwxrwx 2 root root 4096 18 déc. 15:12 /test/ $ ls -l /test/ total 0 -rw-r--r-- 1 user user 0 18 déc. 15:12 test $ sudo ./append $ # pas de problème ici $ sudo chmod +t /test/ $ ls -ld /test/ drwxrwxrwt 2 root root 4096 18 déc. 15:12 /test/ $ ./append $ sudo ./append Traceback (most recent call last): File "/tmp/./append", line 2, in <module> with open('/test/test', 'a'): pass PermissionError: [Errno 13] Permission denied: '/test/test' $ sudo rm /test/test je pensais qu'éventuellement cela pouvait venir du fait que /tmp/ est monté en tmpfs, mais non car le dossier /test/ a le même comportement.
Benoit Izac
Bonjour, Le 18/12/2020 Í 15:20, "" a écrit dans le message  :
$ sudo ./append Traceback (most recent call last): File "/tmp/./append", line 2, in <module> with open('/test/test', 'a'): pass PermissionError: [Errno 13] Permission denied: '/test/test' $ sudo rm /test/test je pensais qu'éventuellement cela pouvait venir du fait que /tmp/ est monté en tmpfs, mais non car le dossier /test/ a le même comportement.
Bonjour, Le 18/12/2020 Í 15:20, "" a écrit dans le message  :
$ sudo ./append Traceback (most recent call last): File "/tmp/./append", line 2, in <module> with open('/test/test', 'a'): pass PermissionError: [Errno 13] Permission denied: '/test/test' $ sudo rm /test/test je pensais qu'éventuellement cela pouvait venir du fait que /tmp/ est monté en tmpfs, mais non car le dossier /test/ a le même comportement.
Merci BenoÍ®t. Tu as très certainement tapé dans le mille. Sur ma Ubuntu 18.04 j'ai ça : ~$ sudo sysctl fs.protected_regular fs.protected_regular = 0 Donc je suis donc sur un comportement « classique ». @lacsaP : et toi, de ton cÍ´té, tu as la valeur 1 je suppose. Tu confirmes ? À+ -- François Lafont
Bonjour,
On 12/18/20 6:38 PM, Benoit Izac wrote:
Je pense que l'explication se trouve ici :
<https://unix.stackexchange.com/questions/503111/group-permissions-for-root-not-working-in-tmp>.
En résumé, c'est propre Í Linux et relativement récent. Pour revenir
Í un comportement plus "classique"Â : «Â sysctl fs.protected_regular=0Â ».
Merci BenoÍ®t. Tu as très certainement tapé dans le mille. Sur ma Ubuntu 18.04
j'ai ça :
Merci BenoÍ®t. Tu as très certainement tapé dans le mille. Sur ma Ubuntu 18.04 j'ai ça : ~$ sudo sysctl fs.protected_regular fs.protected_regular = 0 Donc je suis donc sur un comportement « classique ». @lacsaP : et toi, de ton cÍ´té, tu as la valeur 1 je suppose. Tu confirmes ? À+ -- François Lafont
Alain Ketterlin
"" writes:
le comportement semble cohérent avec ce qui est annoncé sur Wikipedia : """ When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. """ la seule action possible pour root serait de renommer ou supprimer le fichier. ce qui est le cas pour moi :
Non, tu te trompes sur le sens de la phrase : seuls les proriétaires et root peuvent renommer/suprimer, ça ne veut pas dire que root ne peut que supprimer/renommer.
$ cd /tmp/ $ ./append $ sudo mv test toto $ echo test | sudo tee -a toto tee: toto: Permission non accordée test $ sudo rm toto
Tu as eu la solution plus loin dans le thread je pense. -- Alain.
"pata...@gmail.com" <patatetom@gmail.com> writes:
le comportement semble cohérent avec ce qui est annoncé sur Wikipedia :
"""
When a directory's sticky bit is set, the filesystem treats the files
in such directories in a special way so only the file's owner, the
directory's owner, or root user can rename or delete the file.
"""
la seule action possible pour root serait de renommer ou supprimer le fichier.
ce qui est le cas pour moi :
Non, tu te trompes sur le sens de la phrase : seuls les proriétaires et
root peuvent renommer/suprimer, ça ne veut pas dire que root ne peut que
supprimer/renommer.
$ cd /tmp/
$ ./append
$ sudo mv test toto
$ echo test | sudo tee -a toto
tee: toto: Permission non accordée
test
$ sudo rm toto
Tu as eu la solution plus loin dans le thread je pense.
le comportement semble cohérent avec ce qui est annoncé sur Wikipedia : """ When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. """ la seule action possible pour root serait de renommer ou supprimer le fichier. ce qui est le cas pour moi :
Non, tu te trompes sur le sens de la phrase : seuls les proriétaires et root peuvent renommer/suprimer, ça ne veut pas dire que root ne peut que supprimer/renommer.
$ cd /tmp/ $ ./append $ sudo mv test toto $ echo test | sudo tee -a toto tee: toto: Permission non accordée test $ sudo rm toto
Tu as eu la solution plus loin dans le thread je pense. -- Alain.
pata...
bonjour, de mon cÍ´té, avec Archlinux, j'ai effectivement fs.protected_regular = 1. tout rentre dans l'ordre en le passant Í 0. finalement rien Í voir avec Python : désolé. merci Í vous.
bonjour,
de mon cÍ´té, avec Archlinux, j'ai effectivement fs.protected_regular = 1.
tout rentre dans l'ordre en le passant Í 0.
finalement rien Í voir avec Python : désolé.
merci Í vous.
bonjour, de mon cÍ´té, avec Archlinux, j'ai effectivement fs.protected_regular = 1. tout rentre dans l'ordre en le passant Í 0. finalement rien Í voir avec Python : désolé. merci Í vous.
