J'ai tente de mettre en ½uvre les ACL sur une Debian que j'administre
à distance. Et me permet de régler ce problème :
-- je veux faire en sorte que tous les fichiers sous /etc soient
lisibles par l'utilisateur truc qui ne soit pas root ;
-- il ne faut pas changer les propriétaires des fichiers ni ajouter
truc aux groupes d'appartenance des fichiers (comme le groupe shadow,
le groupe adm, etc.) ;
-- positionner tout /etc avec un attribut ACL de droit en lecture pour
truc permet de faire cela facilement.
Mais... Certains ajouts d'ACL à ces fichiers empêchent mon utilisateur
truc de se connecter.
Voici les commandes utilisées et les résultats (je suis en root) :
setfacl -R -m u:truc:r /etc
setfacl: /etc/network/run: Opération non supportée
(normal, c'est un lien symbolique)
setfacl: /etc/network/run/ifstate: Opération non supportée
(là, je ne vois pas pourquoi cela ne passe pas)
su truc
bash: /etc/bash.bashrc: Permission non accordée
(je me retrouve ensuite avec une invite de bash en « I have no
name!@serveurintra »)
exit
(retour à root)
ls -l /etc/bash.bashrc
-rw-r--r--+ 1 root root 983 2005-01-22 23:20 /etc/bash.bashrc
setfacl -R -b /etc
(j'enlève tous les ACL)
ls -l /etc/bash.bashrc
-rw-r--r-- 1 root root 983 2005-01-22 23:20 /etc/bash.bashrc
(à part l'ACL en moins, pas de différence frappante)
su truc
truc@serveurintra:
(bref, ça marche à nouveau)
Impossible après cela de me connecter sous l'identité truc
si /etc/bash.bashrc possède l'ACL en question.
Reste une chose : donner les droits de lecture (et d'exécution / listage des répertoires) à truc de cette manière ne revient-il pas à introduire une faille de sécurité ?
De quel genre ? Par exemple pour /etc/shadow ?
Par exemple.
Je me demande s'il ne vaut pas mieux créer un nouvel utilisateur avec des droits limités dans les autres domaines.
Mais ça il n'y a que vous qui pouvez le savoir, car nous ignorons ce qu'au final vous cherchez à faire avec cet utilisateur truc.
De la maintenance : c'est l'utilisateur qui peut se connecter par ssh, qui appartient au groupe adm (permet, chez moi, de lire les logs) et possède quelques droits d'administration étendus par sudo.
TiChou égrapsen en <bzium.20050524204211@florizarre.tichou.org> :
Reste une chose : donner les droits de lecture (et d'exécution /
listage des répertoires) à truc de cette manière ne revient-il pas
à introduire une faille de sécurité ?
De quel genre ? Par exemple pour /etc/shadow ?
Par exemple.
Je me demande s'il ne vaut pas mieux créer un nouvel utilisateur
avec des droits limités dans les autres domaines.
Mais ça il n'y a que vous qui pouvez le savoir, car nous ignorons ce
qu'au final vous cherchez à faire avec cet utilisateur truc.
De la maintenance : c'est l'utilisateur qui peut se connecter par ssh,
qui appartient au groupe adm (permet, chez moi, de lire les logs) et
possède quelques droits d'administration étendus par sudo.
Reste une chose : donner les droits de lecture (et d'exécution / listage des répertoires) à truc de cette manière ne revient-il pas à introduire une faille de sécurité ?
De quel genre ? Par exemple pour /etc/shadow ?
Par exemple.
Je me demande s'il ne vaut pas mieux créer un nouvel utilisateur avec des droits limités dans les autres domaines.
Mais ça il n'y a que vous qui pouvez le savoir, car nous ignorons ce qu'au final vous cherchez à faire avec cet utilisateur truc.
De la maintenance : c'est l'utilisateur qui peut se connecter par ssh, qui appartient au groupe adm (permet, chez moi, de lire les logs) et possède quelques droits d'administration étendus par sudo.
