sudo python PermissionError [Errno 13] Permission denied

Le
pata...
bonjour,

voici un simple script Python qui teste si le fichier "/tmp/test" peut être ouvert et modifié :

$ cat /tmp/append
#!/usr/bin/python
with open('/tmp/test', 'a'): pass

le fichier n'existe pas encore :

$ chmod +x /tmp/append
$ ls -l /tmp/test
ls: cannot access '/tmp/test': No such file or directory

le script est démarré en tant que simple utilisateur :

$ /tmp/append
$ ls -l /tmp/test
-rw-r--r-- 1 user user 0 Dec 17 10:30 /tmp/test

tout est ok.
maintenant le script échoue s'il est démarré en tant qu'utilisateur root avec la commande sudo :

$ sudo /tmp/append
[sudo] password for user:
Traceback (most recent call last):
File "/tmp/append", line 2, in <module>
with open('/tmp/test', 'a'):
PermissionError: [Errno 13] Permission denied: '/tmp/test'

le problème persiste même si l'ouverture du fichier est faite en mode "'w'" ou si les commandes "sudo -i" ou "su -" sur utilisées.

aucun attribut particulier n'est positionné sur le fichier ou le sous-système de fichiers.

pourquoi le super-utilisateur root ne peut-il pas manipuler le fichier avec Python ?

lacsaP.
  • Partager ce contenu :
Vos réponses Page 1 / 2
Trier par : date / pertinence
yamo'
Le #26563065
Salut,
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
pata...
Le #26563069
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
Le #26563115
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
Alain Ketterlin
Le #26563157
Francois Lafont
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...
Le #26563160
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...
Le #26563162
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
Le #26563169
Bonjour,
Le 18/12/2020 Í  15:20, "" 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.

Je pense que l'explication se trouve ici :
En résumé, c'est propre Í  Linux et relativement récent. Pour revenir
Í  un comportement plus "classique" : «Â sysctl fs.protected_regular=0 ».
--
Benoit Izac
Francois Lafont
Le #26563178
Bonjour,
On 12/18/20 6:38 PM, Benoit Izac wrote:
Je pense que l'explication se trouve ici :
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 :
~$ 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
Le #26563287
""
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...
Le #26563417
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.
Poster une réponse
Anonyme