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.
Dans le message <news:429215f4$0$1718$, *Vincent Ramos* tapota sur f.c.o.l.configuration :
Bonjour,
Bonsoir,
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)
Non, ça n'est pas la réelle raison. Voir ci-dessous.
setfacl: /etc/network/run/ifstate: Opération non supportée (là, je ne vois pas pourquoi cela ne passe pas)
Tout simplement parce que /etc/network/run pointe sur un système de fichier ne supportant pas les ACL.
su truc bash: /etc/bash.bashrc: Permission non accordée
Ce qui veut dire que truc n'a pas l'autorisation de lire ou d'exécuter ce fichier. En toute logique bash essaye juste de lire ce fichier (de le sourcer pour être exact) et s'il n'y arrive pas c'est parce qu'il n'y accède pas. Normal vu les permissions qui ont été définies sur le répertoire parent de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Merci.
De rien.
-- TiChou
Dans le message <news:429215f4$0$1718$636a15ce@news.free.fr>,
*Vincent Ramos* tapota sur f.c.o.l.configuration :
Bonjour,
Bonsoir,
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)
Non, ça n'est pas la réelle raison. Voir ci-dessous.
setfacl: /etc/network/run/ifstate: Opération non supportée
(là, je ne vois pas pourquoi cela ne passe pas)
Tout simplement parce que /etc/network/run pointe sur un système de fichier
ne supportant pas les ACL.
su truc
bash: /etc/bash.bashrc: Permission non accordée
Ce qui veut dire que truc n'a pas l'autorisation de lire ou d'exécuter ce
fichier. En toute logique bash essaye juste de lire ce fichier (de le
sourcer pour être exact) et s'il n'y arrive pas c'est parce qu'il n'y accède
pas. Normal vu les permissions qui ont été définies sur le répertoire parent
de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Dans le message <news:429215f4$0$1718$, *Vincent Ramos* tapota sur f.c.o.l.configuration :
Bonjour,
Bonsoir,
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)
Non, ça n'est pas la réelle raison. Voir ci-dessous.
setfacl: /etc/network/run/ifstate: Opération non supportée (là, je ne vois pas pourquoi cela ne passe pas)
Tout simplement parce que /etc/network/run pointe sur un système de fichier ne supportant pas les ACL.
su truc bash: /etc/bash.bashrc: Permission non accordée
Ce qui veut dire que truc n'a pas l'autorisation de lire ou d'exécuter ce fichier. En toute logique bash essaye juste de lire ce fichier (de le sourcer pour être exact) et s'il n'y arrive pas c'est parce qu'il n'y accède pas. Normal vu les permissions qui ont été définies sur le répertoire parent de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Merci.
De rien.
-- TiChou
Vincent Ramos
TiChou égrapsen en :
setfacl: /etc/network/run: Opération non supportée (normal, c'est un lien symbolique) Non, ça n'est pas la réelle raison. Voir ci-dessous.
setfacl: /etc/network/run/ifstate: Opération non supportée (là, je ne vois pas pourquoi cela ne passe pas) Tout simplement parce que /etc/network/run pointe sur un système de
fichier ne supportant pas les ACL.
Rhââââ... Le truc de débutant... Je n'ai même pas regardé où allait le lien : /dev/*shm*/network...
su truc bash: /etc/bash.bashrc: Permission non accordée
Ce qui veut dire que truc n'a pas l'autorisation de lire ou d'exécuter ce fichier. En toute logique bash essaye juste de lire ce fichier (de le sourcer pour être exact) et s'il n'y arrive pas c'est parce qu'il n'y accède pas. Normal vu les permissions qui ont été définies sur le répertoire parent de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Ce que je ne comprends pas c'est que sans les ACL, truc peut très bien « sourcer » /etc/bash.bashrc alors que les droits sont -rw-r--r-- 1 root root. Pourquoi ajouter un droit en lecture à truc lui retire-t-il la possibilité de « sourcer ».
En tout cas, merci pour ces remarques.
TiChou égrapsen en <pwet.20050523201748@florizarre.tichou.org> :
setfacl: /etc/network/run: Opération non supportée
(normal, c'est un lien symbolique)
Non, ça n'est pas la réelle raison. Voir ci-dessous.
setfacl: /etc/network/run/ifstate: Opération non supportée
(là, je ne vois pas pourquoi cela ne passe pas)
Tout simplement parce que /etc/network/run pointe sur un système de
fichier ne supportant pas les ACL.
Rhââââ... Le truc de débutant... Je n'ai même pas regardé où allait le
lien : /dev/*shm*/network...
su truc
bash: /etc/bash.bashrc: Permission non accordée
Ce qui veut dire que truc n'a pas l'autorisation de lire ou
d'exécuter ce fichier. En toute logique bash essaye juste de lire ce
fichier (de le sourcer pour être exact) et s'il n'y arrive pas c'est
parce qu'il n'y accède pas. Normal vu les permissions qui ont été
définies sur le répertoire parent de ce fichier pour l'utilisateur
truc (u:truc:r et non pas u:truc:rx).
Ce que je ne comprends pas c'est que sans les ACL, truc peut très bien
« sourcer » /etc/bash.bashrc alors que les droits sont -rw-r--r-- 1
root root. Pourquoi ajouter un droit en lecture à truc lui
retire-t-il la possibilité de « sourcer ».
setfacl: /etc/network/run: Opération non supportée (normal, c'est un lien symbolique) Non, ça n'est pas la réelle raison. Voir ci-dessous.
setfacl: /etc/network/run/ifstate: Opération non supportée (là, je ne vois pas pourquoi cela ne passe pas) Tout simplement parce que /etc/network/run pointe sur un système de
fichier ne supportant pas les ACL.
Rhââââ... Le truc de débutant... Je n'ai même pas regardé où allait le lien : /dev/*shm*/network...
su truc bash: /etc/bash.bashrc: Permission non accordée
Ce qui veut dire que truc n'a pas l'autorisation de lire ou d'exécuter ce fichier. En toute logique bash essaye juste de lire ce fichier (de le sourcer pour être exact) et s'il n'y arrive pas c'est parce qu'il n'y accède pas. Normal vu les permissions qui ont été définies sur le répertoire parent de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Ce que je ne comprends pas c'est que sans les ACL, truc peut très bien « sourcer » /etc/bash.bashrc alors que les droits sont -rw-r--r-- 1 root root. Pourquoi ajouter un droit en lecture à truc lui retire-t-il la possibilité de « sourcer ».
En tout cas, merci pour ces remarques.
Vincent Ramos
Vincent Ramos égrapsen en <42923b38$0$6664$ :
Pourquoi ajouter un droit en lecture à truc lui retire-t-il la possibilité de « sourcer ».
Manque un <?> final.
Vincent Ramos égrapsen en <42923b38$0$6664$636a15ce@news.free.fr> :
Pourquoi ajouter un droit en lecture à truc lui retire-t-il la
possibilité de « sourcer ».
Pourquoi ajouter un droit en lecture à truc lui retire-t-il la possibilité de « sourcer ».
Manque un <?> final.
Christophe PEREZ
Le Mon, 23 May 2005 20:34:15 +0200, TiChou a écrit:
Normal vu les permissions qui ont été définies sur le répertoire parent de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Ben tiens, une réponse de TiChou, alors j'en profite.
J'ai toujours été surpris de ne pas trouver, sous Linux, comment donner des droits récursifs à tous les fichiers ET répertoires différemment. Je m'explique. Dans un cas comme celui de ce fil, il faudrait donner r-w à tous les répertoire de /etc et r-- à tous les fichiers. Comment faire ça de façon simple sans utiliser la machine de guerre "find" ?
Et le problème se pose exactement de la même manière avec les ACL. Le -R de la récursivité appliquant les mêmes droits aux répertoires qu'aux fichiers.
C'est une vraie question que je me pose depuis longtemps ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Mon, 23 May 2005 20:34:15 +0200, TiChou a écrit:
Normal vu les permissions qui ont été définies sur le répertoire parent
de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Ben tiens, une réponse de TiChou, alors j'en profite.
J'ai toujours été surpris de ne pas trouver, sous Linux, comment donner
des droits récursifs à tous les fichiers ET répertoires différemment.
Je m'explique.
Dans un cas comme celui de ce fil, il faudrait donner r-w à tous les
répertoire de /etc et r-- à tous les fichiers.
Comment faire ça de façon simple sans utiliser la machine de guerre
"find" ?
Et le problème se pose exactement de la même manière avec les ACL. Le
-R de la récursivité appliquant les mêmes droits aux répertoires
qu'aux fichiers.
C'est une vraie question que je me pose depuis longtemps ;-)
Le Mon, 23 May 2005 20:34:15 +0200, TiChou a écrit:
Normal vu les permissions qui ont été définies sur le répertoire parent de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Ben tiens, une réponse de TiChou, alors j'en profite.
J'ai toujours été surpris de ne pas trouver, sous Linux, comment donner des droits récursifs à tous les fichiers ET répertoires différemment. Je m'explique. Dans un cas comme celui de ce fil, il faudrait donner r-w à tous les répertoire de /etc et r-- à tous les fichiers. Comment faire ça de façon simple sans utiliser la machine de guerre "find" ?
Et le problème se pose exactement de la même manière avec les ACL. Le -R de la récursivité appliquant les mêmes droits aux répertoires qu'aux fichiers.
C'est une vraie question que je me pose depuis longtemps ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
TiChou
Dans le message <news:42923b38$0$6664$, *Vincent Ramos* tapota sur f.c.o.l.configuration :
Ce qui veut dire que truc n'a pas l'autorisation de lire ou d'exécuter ce fichier. En toute logique bash essaye juste de lire ce fichier (de le sourcer pour être exact) et s'il n'y arrive pas c'est parce qu'il n'y accède pas. Normal vu les permissions qui ont été définies sur le répertoire parent de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Ce que je ne comprends pas c'est que sans les ACL, truc peut très bien « sourcer » /etc/bash.bashrc alors que les droits sont -rw-r--r-- 1 root root. Pourquoi ajouter un droit en lecture à truc lui retire-t-il la possibilité de « sourcer ».
Là n'est pas le problème. Avec les ACL truc a toujours un droit de lecture sur le fichier /etc/bash.bashrc mais il n'a pas un droit d'accès au répertoire /etc puisque celui-ci a comme mode r et pas x, donc il ne peut accéder au fichier /etc/bash.bashrc.
-- TiChou
Dans le message <news:42923b38$0$6664$636a15ce@news.free.fr>,
*Vincent Ramos* tapota sur f.c.o.l.configuration :
Ce qui veut dire que truc n'a pas l'autorisation de lire ou
d'exécuter ce fichier. En toute logique bash essaye juste de lire ce
fichier (de le sourcer pour être exact) et s'il n'y arrive pas c'est
parce qu'il n'y accède pas. Normal vu les permissions qui ont été
définies sur le répertoire parent de ce fichier pour l'utilisateur
truc (u:truc:r et non pas u:truc:rx).
Ce que je ne comprends pas c'est que sans les ACL, truc peut très bien
« sourcer » /etc/bash.bashrc alors que les droits sont -rw-r--r-- 1
root root. Pourquoi ajouter un droit en lecture à truc lui
retire-t-il la possibilité de « sourcer ».
Là n'est pas le problème. Avec les ACL truc a toujours un droit de lecture
sur le fichier /etc/bash.bashrc mais il n'a pas un droit d'accès au
répertoire /etc puisque celui-ci a comme mode r et pas x, donc il ne peut
accéder au fichier /etc/bash.bashrc.
Dans le message <news:42923b38$0$6664$, *Vincent Ramos* tapota sur f.c.o.l.configuration :
Ce qui veut dire que truc n'a pas l'autorisation de lire ou d'exécuter ce fichier. En toute logique bash essaye juste de lire ce fichier (de le sourcer pour être exact) et s'il n'y arrive pas c'est parce qu'il n'y accède pas. Normal vu les permissions qui ont été définies sur le répertoire parent de ce fichier pour l'utilisateur truc (u:truc:r et non pas u:truc:rx).
Ce que je ne comprends pas c'est que sans les ACL, truc peut très bien « sourcer » /etc/bash.bashrc alors que les droits sont -rw-r--r-- 1 root root. Pourquoi ajouter un droit en lecture à truc lui retire-t-il la possibilité de « sourcer ».
Là n'est pas le problème. Avec les ACL truc a toujours un droit de lecture sur le fichier /etc/bash.bashrc mais il n'a pas un droit d'accès au répertoire /etc puisque celui-ci a comme mode r et pas x, donc il ne peut accéder au fichier /etc/bash.bashrc.
-- TiChou
TiChou
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Salut Christophe,
J'ai toujours été surpris de ne pas trouver, sous Linux, comment donner des droits récursifs à tous les fichiers ET répertoires différemment. Je m'explique. Dans un cas comme celui de ce fil, il faudrait donner r-w à tous les répertoire de /etc
r-x, mais j'imagine qu'il s'agit d'une faute de frappe. :)
et r-- à tous les fichiers. Comment faire ça de façon simple sans utiliser la machine de guerre "find" ?
On ne peut pas vraiment. Ou alors, il reste possible de mettre la permission x uniquement aux répertoires seulement si les fichiers n'ont pas la permission x en utilisant la permission spéciale X de chmod. Sinon, il faut jouer avec les opérateurs -, + et =. Par exemple :
$ chmod -R u=rwX,go= /path
Et le problème se pose exactement de la même manière avec les ACL. Le -R de la récursivité appliquant les mêmes droits aux répertoires qu'aux fichiers.
Le principe reste le même qu'avec chmod.
J'espère avoir été suffisement clair. EN gros ce qu'il faut comprendre c'est que oui ça reste possible, mais pas dans tous les cas.
-- TiChou
Dans le message <news:pan.2005.05.23.20.31.20.271452@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
Salut Christophe,
J'ai toujours été surpris de ne pas trouver, sous Linux, comment donner
des droits récursifs à tous les fichiers ET répertoires différemment.
Je m'explique.
Dans un cas comme celui de ce fil, il faudrait donner r-w à tous les
répertoire de /etc
r-x, mais j'imagine qu'il s'agit d'une faute de frappe. :)
et r-- à tous les fichiers.
Comment faire ça de façon simple sans utiliser la machine de guerre
"find" ?
On ne peut pas vraiment. Ou alors, il reste possible de mettre la permission
x uniquement aux répertoires seulement si les fichiers n'ont pas la
permission x en utilisant la permission spéciale X de chmod. Sinon, il faut
jouer avec les opérateurs -, + et =. Par exemple :
$ chmod -R u=rwX,go= /path
Et le problème se pose exactement de la même manière avec les ACL. Le
-R de la récursivité appliquant les mêmes droits aux répertoires
qu'aux fichiers.
Le principe reste le même qu'avec chmod.
J'espère avoir été suffisement clair. EN gros ce qu'il faut comprendre c'est
que oui ça reste possible, mais pas dans tous les cas.
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
Salut Christophe,
J'ai toujours été surpris de ne pas trouver, sous Linux, comment donner des droits récursifs à tous les fichiers ET répertoires différemment. Je m'explique. Dans un cas comme celui de ce fil, il faudrait donner r-w à tous les répertoire de /etc
r-x, mais j'imagine qu'il s'agit d'une faute de frappe. :)
et r-- à tous les fichiers. Comment faire ça de façon simple sans utiliser la machine de guerre "find" ?
On ne peut pas vraiment. Ou alors, il reste possible de mettre la permission x uniquement aux répertoires seulement si les fichiers n'ont pas la permission x en utilisant la permission spéciale X de chmod. Sinon, il faut jouer avec les opérateurs -, + et =. Par exemple :
$ chmod -R u=rwX,go= /path
Et le problème se pose exactement de la même manière avec les ACL. Le -R de la récursivité appliquant les mêmes droits aux répertoires qu'aux fichiers.
Le principe reste le même qu'avec chmod.
J'espère avoir été suffisement clair. EN gros ce qu'il faut comprendre c'est que oui ça reste possible, mais pas dans tous les cas.
-- TiChou
Vincent Ramos
TiChou égrapsen en :
Ce que je ne comprends pas c'est que sans les ACL, truc peut très bien « sourcer » /etc/bash.bashrc alors que les droits sont -rw-r--r-- 1 root root. Pourquoi ajouter un droit en lecture à truc lui retire-t-il la possibilité de « sourcer ».
Là n'est pas le problème. Avec les ACL truc a toujours un droit de lecture sur le fichier /etc/bash.bashrc mais il n'a pas un droit d'accès au répertoire /etc puisque celui-ci a comme mode r et pas x, donc il ne peut accéder au fichier /etc/bash.bashrc.
Donc, si j'ai bien compris, l'ACL « r mais pas x » prend le pas sur les droits normaux ?
TiChou égrapsen en <bzium.20050523222902@florizarre.tichou.org> :
Ce que je ne comprends pas c'est que sans les ACL, truc peut très
bien
« sourcer » /etc/bash.bashrc alors que les droits sont -rw-r--r--
1 root root. Pourquoi ajouter un droit en lecture à truc lui
retire-t-il la possibilité de « sourcer ».
Là n'est pas le problème. Avec les ACL truc a toujours un droit de
lecture sur le fichier /etc/bash.bashrc mais il n'a pas un droit
d'accès au répertoire /etc puisque celui-ci a comme mode r et pas x,
donc il ne peut accéder au fichier /etc/bash.bashrc.
Donc, si j'ai bien compris, l'ACL « r mais pas x » prend le pas sur
les droits normaux ?
Ce que je ne comprends pas c'est que sans les ACL, truc peut très bien « sourcer » /etc/bash.bashrc alors que les droits sont -rw-r--r-- 1 root root. Pourquoi ajouter un droit en lecture à truc lui retire-t-il la possibilité de « sourcer ».
Là n'est pas le problème. Avec les ACL truc a toujours un droit de lecture sur le fichier /etc/bash.bashrc mais il n'a pas un droit d'accès au répertoire /etc puisque celui-ci a comme mode r et pas x, donc il ne peut accéder au fichier /etc/bash.bashrc.
Donc, si j'ai bien compris, l'ACL « r mais pas x » prend le pas sur les droits normaux ?
Vincent Ramos
TiChou égrapsen en :
Là n'est pas le problème. Avec les ACL truc a toujours un droit de lecture sur le fichier /etc/bash.bashrc mais il n'a pas un droit d'accès au répertoire /etc puisque celui-ci a comme mode r et pas x, donc il ne peut accéder au fichier /etc/bash.bashrc.
Je viens d'essayer en ajoutant le droit x : cela marche maintenant très bien.
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é ? Au final, le mot de passe de mon utilisateur truc n'a pas intérêt à être récupéré car il a maintenant accès à tout /etc.
Je me demande s'il ne vaut pas mieux créer un nouvel utilisateur avec des droits limités dans les autres domaines.
TiChou égrapsen en <bzium.20050523222902@florizarre.tichou.org> :
Là n'est pas le problème. Avec les ACL truc a toujours un droit de
lecture sur le fichier /etc/bash.bashrc mais il n'a pas un droit
d'accès au répertoire /etc puisque celui-ci a comme mode r et pas x,
donc il ne peut accéder au fichier /etc/bash.bashrc.
Je viens d'essayer en ajoutant le droit x : cela marche maintenant
très bien.
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é ? Au final, le mot de passe de mon
utilisateur truc n'a pas intérêt à être récupéré car il a maintenant
accès à tout /etc.
Je me demande s'il ne vaut pas mieux créer un nouvel utilisateur avec
des droits limités dans les autres domaines.
Là n'est pas le problème. Avec les ACL truc a toujours un droit de lecture sur le fichier /etc/bash.bashrc mais il n'a pas un droit d'accès au répertoire /etc puisque celui-ci a comme mode r et pas x, donc il ne peut accéder au fichier /etc/bash.bashrc.
Je viens d'essayer en ajoutant le droit x : cela marche maintenant très bien.
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é ? Au final, le mot de passe de mon utilisateur truc n'a pas intérêt à être récupéré car il a maintenant accès à tout /etc.
Je me demande s'il ne vaut pas mieux créer un nouvel utilisateur avec des droits limités dans les autres domaines.
Christophe PEREZ
Le Mon, 23 May 2005 23:24:47 +0200, TiChou a écrit:
r-x, mais j'imagine qu'il s'agit d'une faute de frappe. :)
Bien entendu ;-)
On ne peut pas vraiment. Ou alors, il reste possible de mettre la permission x uniquement aux répertoires seulement si les fichiers n'ont pas la permission x en utilisant la permission spéciale X de chmod. Sinon, il faut jouer avec les opérateurs -, + et =. Par exemple :
$ chmod -R u=rwX,go= /path
Ok, je vais refaire un man chmod pour voir tout ça ;-)
Le principe reste le même qu'avec chmod.
C'est bien ce que j'avais cru comprendre à force.
J'espère avoir été suffisement clair.
Oui, sauf sur le chmod, mais là c'est moi qui ne connaît pas suffisamment bien.
EN gros ce qu'il faut comprendre c'est que oui ça reste possible, mais pas dans tous les cas.
Mouais, et c'est bien dommage. Mais surtout, je suis surpris que personne n'ai fait la commande qui-va-bien, car dans l'absolu, si on peut traiter ça avec des find etc... on pourrait aussi avoir une commande native qui le fasse non ? Je précise que je ne suis pas apte à faire cette commande, au cas où quelqu'un s'aventurerait à me proposer de m'y mettre ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Mon, 23 May 2005 23:24:47 +0200, TiChou a écrit:
r-x, mais j'imagine qu'il s'agit d'une faute de frappe. :)
Bien entendu ;-)
On ne peut pas vraiment. Ou alors, il reste possible de mettre la permission
x uniquement aux répertoires seulement si les fichiers n'ont pas la
permission x en utilisant la permission spéciale X de chmod. Sinon, il faut
jouer avec les opérateurs -, + et =. Par exemple :
$ chmod -R u=rwX,go= /path
Ok, je vais refaire un man chmod pour voir tout ça ;-)
Le principe reste le même qu'avec chmod.
C'est bien ce que j'avais cru comprendre à force.
J'espère avoir été suffisement clair.
Oui, sauf sur le chmod, mais là c'est moi qui ne connaît pas
suffisamment bien.
EN gros ce qu'il faut comprendre c'est
que oui ça reste possible, mais pas dans tous les cas.
Mouais, et c'est bien dommage. Mais surtout, je suis surpris que personne
n'ai fait la commande qui-va-bien, car dans l'absolu, si on peut traiter
ça avec des find etc... on pourrait aussi avoir une commande native qui
le fasse non ?
Je précise que je ne suis pas apte à faire cette commande, au cas où
quelqu'un s'aventurerait à me proposer de m'y mettre ;-)
Le Mon, 23 May 2005 23:24:47 +0200, TiChou a écrit:
r-x, mais j'imagine qu'il s'agit d'une faute de frappe. :)
Bien entendu ;-)
On ne peut pas vraiment. Ou alors, il reste possible de mettre la permission x uniquement aux répertoires seulement si les fichiers n'ont pas la permission x en utilisant la permission spéciale X de chmod. Sinon, il faut jouer avec les opérateurs -, + et =. Par exemple :
$ chmod -R u=rwX,go= /path
Ok, je vais refaire un man chmod pour voir tout ça ;-)
Le principe reste le même qu'avec chmod.
C'est bien ce que j'avais cru comprendre à force.
J'espère avoir été suffisement clair.
Oui, sauf sur le chmod, mais là c'est moi qui ne connaît pas suffisamment bien.
EN gros ce qu'il faut comprendre c'est que oui ça reste possible, mais pas dans tous les cas.
Mouais, et c'est bien dommage. Mais surtout, je suis surpris que personne n'ai fait la commande qui-va-bien, car dans l'absolu, si on peut traiter ça avec des find etc... on pourrait aussi avoir une commande native qui le fasse non ? Je précise que je ne suis pas apte à faire cette commande, au cas où quelqu'un s'aventurerait à me proposer de m'y mettre ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
TiChou
Dans le message <news:42925031$0$6588$, *Vincent Ramos* tapota sur f.c.o.l.configuration :
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 ?
Au final, le mot de passe de mon utilisateur truc n'a pas intérêt à être récupéré car il a maintenant accès à tout /etc.
Il a accès en lecture. Mais, sur un Linux classique, un utilisateur normal a déjà accès en lecture à presque toute l'arborsence de /etc.
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.
-- TiChou
Dans le message <news:42925031$0$6588$626a14ce@news.free.fr>,
*Vincent Ramos* tapota sur f.c.o.l.configuration :
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 ?
Au final, le mot de passe de mon utilisateur truc n'a pas intérêt à être
récupéré car il a maintenant accès à tout /etc.
Il a accès en lecture. Mais, sur un Linux classique, un utilisateur normal a
déjà accès en lecture à presque toute l'arborsence de /etc.
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.
Dans le message <news:42925031$0$6588$, *Vincent Ramos* tapota sur f.c.o.l.configuration :
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 ?
Au final, le mot de passe de mon utilisateur truc n'a pas intérêt à être récupéré car il a maintenant accès à tout /etc.
Il a accès en lecture. Mais, sur un Linux classique, un utilisateur normal a déjà accès en lecture à presque toute l'arborsence de /etc.
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.
