Discussion :

[rambc]

Bonjour,
tout est dans le titre. Comment peut-on savoir si le script Python a été lancé ou non en mode Super Utilisateur ?

Existe-t-il une solution marchant sous Linux, Windaube et Mac O$ ?

[wiztricks]

Salut,

Sous les U*X, le group id devrait donner l'information.

Pour Windows et les modèles de sécurité "modernes", le droit adhoc a été donné ou pas à l'utilisateur, au process,...
Dans ce cas, vous avez aussi une primitive système permettant de savoir si vous avez le droit d'accès/modification de l'objet X.
Normalement, try...except... et un message d'erreur "suffisent".

Pourquoi voulez vous faire plus que "good enough"?
- W

[plxpy]

Sous linux/unix/macOsX, tu vas avoir l'info via os.getuid.

Mais attention : 'super utilisateur', c'est vague. Sous MacOSX, beaucoup de taches d'administration se font sous le username 'admin' et pas forcément 'root'.

De plus, getuid te retourne un entier : 0 pour root, mais pour admin ? (pas de macosx sous la main, là, tout de suite). Si, pour admin, ça peut varier d'une machine à l'autre, il te faudra faire l'association entre le no retourné et le username 'admin'

Et comment réagit os.getuid lors d'un lancement via "sudo" ? faut essayer

sous ubuntu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
plx@satellite:~$ more getuid.py
import os
print os.getuid()
plx@satellite:~$ 
plx@satellite:~$ python getuid.py 
1000
plx@satellite:~$ id
uid=1000(plx) gid=1000(plx) groupes=1000(plx),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lpadmin),123(sambashare)
plx@satellite:~$ 
plx@satellite:~$ sudo python getuid.py 
[sudo] password for plx:
0
plx@satellite:~$

[wiztricks]

Salut,

Mais attention : 'super utilisateur', c'est vague. Sous MacOSX, beaucoup de taches d'administration se font sous le username 'admin' et pas forcément 'root'.

Sous UNIX/Posix le super user est root et son (uid, gid) est (0, 0).
Tout le reste est "customisé" en fonction de la distro (OSX est un parent lointain de BSD) ou d'un historique de la "sécurité" spécifique à chaque client.
- W

[tyrtamos]

Bonjour,

Dans les linux traditionnels, root a un uid de 0. Mais il me semble que dans les OS actuels, la mode est plutôt à attribuer ou pas les privilèges d'administrateur à un utilisateur "normal". Ce qui explique que sous Windows, Linux Ubuntu (et dérivés) et Mac OX X, les tâches d'administrations ne demande que le mot de passe utilisateur.

Sous Ubuntu, je crois que les privilèges administrateur sont donnés à un utilisateur "normal" par son appartenance au groupe "sudo", et c'est le fichier /etc/sudoer qui définit les droits.

Avec Ubuntu, il faudrait donc tester si l'utilisateur est soit root (qui peut exister sous Ubuntu), soit appartient au groupe sudo.

Pour Windows ou Mac OS X je ne sais pas, mais il y a peut-être des astuces similaires.

[PauseKawa]

Bonsoir,

Pourquoi ne pas tester "l'interdit" ?

touch /root/test.txt
touch: impossible de faire un touch «/root/test.txt»: Permission non accordée

Il suffit de définir ce qui est 'only root' pour chaque système et try/except passeras très bien (Bien que... sudo rm /root/test.txt).

@+

[rambc]

Merci pour vos réponses.

Normalement, try...except... et un message d'erreur "suffisent". Pourquoi voulez vous faire plus que "good enough"?

A la base je cherchais une méthode propre en espérant qu'un module ad hoc proposerait cela.

Pourquoi ne pas tester "l'interdit" ?

Il suffit de définir ce qui est 'only root' pour chaque système et try/except passeras très bien (Bien que... sudo rm /root/test.txt).

Pas idiot car là on peut passer par subprocess pour voir si une erreur est renvoyée. Dans ce cas, quelle commande interdite et non invasive peut-on utiliser sous Windaube ? Cette question m'intéresse même si j'ai dû opter pour des try... except... en particularisant mes messages d'erreur ce qui est pénible à gérer.