Dans notre entreprise, nous disposons d'un serveur de fichier sous
windows 2000 sur laquelle nous avons crée un ensemble de droits assez
complexe. Nous avons même crée une application pour gérer ça, et nous
enregistrons les droits et les profils dans une base de données afin
d'assigner/modifier/supprimer les droits en fonction des changements.
Maintenant, nous voudrions passer sous unix. Nous avons déjà un serveur
de fichiers avec Samba et une gestion des droits aussi complexe mais
manuelle.
Je me demandais s'il existait une application qui permet de gérer des
profils, des groupes, des utilisateurs, des sous-répertoires, des rôles
d'accès, pour gérer ça.
Une sorte d'appli générique de manipulation des droits unix (je ne parle
pas d'appli graphique, mais plutôt d'un gestionnaire d'arborescence)
Une sorte d'appli générique de manipulation des droits unix (je ne parle pas d'appli graphique, mais plutôt d'un gestionnaire d'arborescence)
"ls -l" pour la visualisation "chmod", "chown" et "chgrp" pour l'édition.
Nicolas Ecarnot
Nicolas Ecarnot wrote in news::
Bonjour,
Dans notre entreprise, nous disposons d'un serveur de fichier sous windows 2000 sur laquelle nous avons crée un ensemble de droits assez complexe. Nous avons même crée une application pour gérer ça, et nous enregistrons les droits et les profils dans une base de données afin d'assigner/modifier/supprimer les droits en fonction des changements.
Maintenant, nous voudrions passer sous unix. Nous avons déjà un serveur de fichiers avec Samba et une gestion des droits aussi complexe mais manuelle.
Je me demandais s'il existait une application qui permet de gérer des profils, des groupes, des utilisateurs, des sous-répertoires, des rôles d'accès, pour gérer ça. Une sorte d'appli générique de manipulation des droits unix (je ne parle pas d'appli graphique, mais plutôt d'un gestionnaire d'arborescence)
Ca vous inspire ?
Après quelques recherches (supplémentaires), je vois un peu ce qui existe et qui pourrait m'aider : - "petal" sous linux, qui lit un fichier de config - "mtree" sous freebsd (bien que je sache pas si mtree peut *assigner* des droits (mais j'imagine que si, ou alors c'est vite fait avec un script)
Mais il n'empèche que dans les deux cas, cela demande de construire le fichier de config, et c'est bien ce point qui est le souci et la cause de mon thread. Plus j'y réflechi, et plus je crois qu'il va falloir utiliser un nombre de groupes hallucinant. Et j'ai cru voir que ce nombre était limité selon les unix.
* Connaissez-vous le nombre max de groupes sous linux ? Sous *BSD ? * Peut-on le changer ? * Qu'y risque-t-on ?
-- Nicolas Ecarnot
Nicolas Ecarnot <nicolas.pas.de.spam@ecarnot.pas.de.spam.net> wrote in
news:slrnbpv8ov.5ua.nicolas.pas.de.spam@pcig135-nec.acc.fr:
Bonjour,
Dans notre entreprise, nous disposons d'un serveur de fichier sous
windows 2000 sur laquelle nous avons crée un ensemble de droits assez
complexe. Nous avons même crée une application pour gérer ça, et nous
enregistrons les droits et les profils dans une base de données afin
d'assigner/modifier/supprimer les droits en fonction des changements.
Maintenant, nous voudrions passer sous unix. Nous avons déjà un
serveur de fichiers avec Samba et une gestion des droits aussi
complexe mais manuelle.
Je me demandais s'il existait une application qui permet de gérer des
profils, des groupes, des utilisateurs, des sous-répertoires, des
rôles d'accès, pour gérer ça.
Une sorte d'appli générique de manipulation des droits unix (je ne
parle pas d'appli graphique, mais plutôt d'un gestionnaire
d'arborescence)
Ca vous inspire ?
Après quelques recherches (supplémentaires), je vois un peu ce qui
existe et qui pourrait m'aider : - "petal" sous linux, qui lit un
fichier de config - "mtree" sous freebsd (bien que je sache pas si mtree
peut *assigner* des droits (mais j'imagine que si, ou alors c'est vite
fait avec un script)
Mais il n'empèche que dans les deux cas, cela demande de construire le
fichier de config, et c'est bien ce point qui est le souci et la cause
de mon thread. Plus j'y réflechi, et plus je crois qu'il va falloir
utiliser un nombre de groupes hallucinant. Et j'ai cru voir que ce
nombre était limité selon les unix.
* Connaissez-vous le nombre max de groupes sous linux ? Sous *BSD ?
* Peut-on le changer ?
* Qu'y risque-t-on ?
Dans notre entreprise, nous disposons d'un serveur de fichier sous windows 2000 sur laquelle nous avons crée un ensemble de droits assez complexe. Nous avons même crée une application pour gérer ça, et nous enregistrons les droits et les profils dans une base de données afin d'assigner/modifier/supprimer les droits en fonction des changements.
Maintenant, nous voudrions passer sous unix. Nous avons déjà un serveur de fichiers avec Samba et une gestion des droits aussi complexe mais manuelle.
Je me demandais s'il existait une application qui permet de gérer des profils, des groupes, des utilisateurs, des sous-répertoires, des rôles d'accès, pour gérer ça. Une sorte d'appli générique de manipulation des droits unix (je ne parle pas d'appli graphique, mais plutôt d'un gestionnaire d'arborescence)
Ca vous inspire ?
Après quelques recherches (supplémentaires), je vois un peu ce qui existe et qui pourrait m'aider : - "petal" sous linux, qui lit un fichier de config - "mtree" sous freebsd (bien que je sache pas si mtree peut *assigner* des droits (mais j'imagine que si, ou alors c'est vite fait avec un script)
Mais il n'empèche que dans les deux cas, cela demande de construire le fichier de config, et c'est bien ce point qui est le souci et la cause de mon thread. Plus j'y réflechi, et plus je crois qu'il va falloir utiliser un nombre de groupes hallucinant. Et j'ai cru voir que ce nombre était limité selon les unix.
* Connaissez-vous le nombre max de groupes sous linux ? Sous *BSD ? * Peut-on le changer ? * Qu'y risque-t-on ?
-- Nicolas Ecarnot
Emmanuel Florac
Dans article , disait...
Je me demandais s'il existait une application qui permet de gérer des profils, des groupes, des utilisateurs, des sous-répertoires, des rôles d'accès, pour gérer ça.
Normalement, tu peux gérer les droits (ACLs) à partir d'une machine windows. Pour la performance, il faut utiliser XFS (qui permet de stocker les ACL windows dans les métadonnées du FS et pas à côté). ENfin il y a d'excellents outlis de gestion des ACLs sous ...IRIX. Mais tu n'as pas mentionné l'OS que tu utilises.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <slrnbpv8ov.5ua.nicolas.pas.de.spam@pcig135-nec.acc.fr>,
nicolas.pas.de.spam@ecarnot.pas.de.spam.net disait...
Je me demandais s'il existait une application qui permet de gérer des
profils, des groupes, des utilisateurs, des sous-répertoires, des rôles
d'accès, pour gérer ça.
Normalement, tu peux gérer les droits (ACLs) à partir d'une machine
windows. Pour la performance, il faut utiliser XFS (qui permet de stocker
les ACL windows dans les métadonnées du FS et pas à côté). ENfin il y a
d'excellents outlis de gestion des ACLs sous ...IRIX. Mais tu n'as pas
mentionné l'OS que tu utilises.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Je me demandais s'il existait une application qui permet de gérer des profils, des groupes, des utilisateurs, des sous-répertoires, des rôles d'accès, pour gérer ça.
Normalement, tu peux gérer les droits (ACLs) à partir d'une machine windows. Pour la performance, il faut utiliser XFS (qui permet de stocker les ACL windows dans les métadonnées du FS et pas à côté). ENfin il y a d'excellents outlis de gestion des ACLs sous ...IRIX. Mais tu n'as pas mentionné l'OS que tu utilises.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Nicolas Ecarnot
Le Wed, 29 Oct 2003 15:24:06 +0100, Emmanuel Florac disait :
Dans article , disait...
Je me demandais s'il existait une application qui permet de gérer des profils, des groupes, des utilisateurs, des sous-répertoires, des rôles d'accès, pour gérer ça.
Normalement, tu peux gérer les droits (ACLs) à partir d'une machine windows. Pour la performance, il faut utiliser XFS (qui permet de stocker les ACL windows dans les métadonnées du FS et pas à côté). ENfin il y a d'excellents outlis de gestion des ACLs sous ...IRIX. Mais tu n'as pas mentionné l'OS que tu utilises.
Je n'ai rien mentionné car ma problématique s'applique à tous les unix. De plus, ma problématique ne s'arrête pas non plus aux ACL :
Imagine que tu gères un serveur de fichiers, avec des centaines d'utilisateurs, et plusieurs centaines de milliers de fichiers. Imagine que pendant des années tu as définis des droits, des accès, des particularités selon les utilisateurs qui te demande tel ou tel accès à tel ou tel sous-répertoire.
Un jour, ton boss te demande un compte-rendu pour connaître la liste complète des accès de Monsieur Bidule, ou à l'inverse, connaître la liste des utilisateurs qui accèdent à tel sous-répertoire.
Comment-fais tu ?
-- Nicolas Ecarnot
Le Wed, 29 Oct 2003 15:24:06 +0100,
Emmanuel Florac <eflorac@verisign.com> disait :
Dans article <slrnbpv8ov.5ua.nicolas.pas.de.spam@pcig135-nec.acc.fr>,
nicolas.pas.de.spam@ecarnot.pas.de.spam.net disait...
Je me demandais s'il existait une application qui permet de gérer des
profils, des groupes, des utilisateurs, des sous-répertoires, des rôles
d'accès, pour gérer ça.
Normalement, tu peux gérer les droits (ACLs) à partir d'une machine
windows. Pour la performance, il faut utiliser XFS (qui permet de stocker
les ACL windows dans les métadonnées du FS et pas à côté). ENfin il y a
d'excellents outlis de gestion des ACLs sous ...IRIX. Mais tu n'as pas
mentionné l'OS que tu utilises.
Je n'ai rien mentionné car ma problématique s'applique à tous les unix.
De plus, ma problématique ne s'arrête pas non plus aux ACL :
Imagine que tu gères un serveur de fichiers, avec des centaines
d'utilisateurs, et plusieurs centaines de milliers de fichiers.
Imagine que pendant des années tu as définis des droits, des accès, des
particularités selon les utilisateurs qui te demande tel ou tel accès à
tel ou tel sous-répertoire.
Un jour, ton boss te demande un compte-rendu pour connaître la liste
complète des accès de Monsieur Bidule, ou à l'inverse, connaître la
liste des utilisateurs qui accèdent à tel sous-répertoire.
Le Wed, 29 Oct 2003 15:24:06 +0100, Emmanuel Florac disait :
Dans article , disait...
Je me demandais s'il existait une application qui permet de gérer des profils, des groupes, des utilisateurs, des sous-répertoires, des rôles d'accès, pour gérer ça.
Normalement, tu peux gérer les droits (ACLs) à partir d'une machine windows. Pour la performance, il faut utiliser XFS (qui permet de stocker les ACL windows dans les métadonnées du FS et pas à côté). ENfin il y a d'excellents outlis de gestion des ACLs sous ...IRIX. Mais tu n'as pas mentionné l'OS que tu utilises.
Je n'ai rien mentionné car ma problématique s'applique à tous les unix. De plus, ma problématique ne s'arrête pas non plus aux ACL :
Imagine que tu gères un serveur de fichiers, avec des centaines d'utilisateurs, et plusieurs centaines de milliers de fichiers. Imagine que pendant des années tu as définis des droits, des accès, des particularités selon les utilisateurs qui te demande tel ou tel accès à tel ou tel sous-répertoire.
Un jour, ton boss te demande un compte-rendu pour connaître la liste complète des accès de Monsieur Bidule, ou à l'inverse, connaître la liste des utilisateurs qui accèdent à tel sous-répertoire.
Comment-fais tu ?
-- Nicolas Ecarnot
Thomas Nemeth
Le mer 29 oct 2003 à 15:54, Nicolas Ecarnot a tapoté : | | Imagine que tu gères un serveur de fichiers, avec des centaines | d'utilisateurs, et plusieurs centaines de milliers de fichiers. | Imagine que pendant des années tu as définis des droits, des accès, des | particularités selon les utilisateurs qui te demande tel ou tel accès à | tel ou tel sous-répertoire. | | Un jour, ton boss te demande un compte-rendu pour connaître la liste | complète des accès de Monsieur Bidule, ou à l'inverse, connaître la | liste des utilisateurs qui accèdent à tel sous-répertoire. | | Comment-fais tu ?
Facile ;)
Cas 1 :
$ grep bidule /etc/group # à utiliser avec awk pour virer le login des autres utilisateurs si # besoin est.
Thomas -- Ta mère elle cherche un micro-dénoyauteur.
Le mer 29 oct 2003 à 15:54, Nicolas Ecarnot a tapoté :
|
| Imagine que tu gères un serveur de fichiers, avec des centaines
| d'utilisateurs, et plusieurs centaines de milliers de fichiers.
| Imagine que pendant des années tu as définis des droits, des accès, des
| particularités selon les utilisateurs qui te demande tel ou tel accès à
| tel ou tel sous-répertoire.
|
| Un jour, ton boss te demande un compte-rendu pour connaître la liste
| complète des accès de Monsieur Bidule, ou à l'inverse, connaître la
| liste des utilisateurs qui accèdent à tel sous-répertoire.
|
| Comment-fais tu ?
Facile ;)
Cas 1 :
$ grep bidule /etc/group
# à utiliser avec awk pour virer le login des autres utilisateurs si
# besoin est.
Le mer 29 oct 2003 à 15:54, Nicolas Ecarnot a tapoté : | | Imagine que tu gères un serveur de fichiers, avec des centaines | d'utilisateurs, et plusieurs centaines de milliers de fichiers. | Imagine que pendant des années tu as définis des droits, des accès, des | particularités selon les utilisateurs qui te demande tel ou tel accès à | tel ou tel sous-répertoire. | | Un jour, ton boss te demande un compte-rendu pour connaître la liste | complète des accès de Monsieur Bidule, ou à l'inverse, connaître la | liste des utilisateurs qui accèdent à tel sous-répertoire. | | Comment-fais tu ?
Facile ;)
Cas 1 :
$ grep bidule /etc/group # à utiliser avec awk pour virer le login des autres utilisateurs si # besoin est.
Thomas -- Ta mère elle cherche un micro-dénoyauteur.
Nicolas Ecarnot
Le 29 Oct 2003 14:58:44 GMT, Thomas Nemeth disait :
Le mer 29 oct 2003 à 15:54, Nicolas Ecarnot a tapoté : | | Imagine que tu gères un serveur de fichiers, avec des centaines | d'utilisateurs, et plusieurs centaines de milliers de fichiers. | Imagine que pendant des années tu as définis des droits, des accès, des | particularités selon les utilisateurs qui te demande tel ou tel accès à | tel ou tel sous-répertoire. | | Un jour, ton boss te demande un compte-rendu pour connaître la liste | complète des accès de Monsieur Bidule, ou à l'inverse, connaître la | liste des utilisateurs qui accèdent à tel sous-répertoire. | | Comment-fais tu ?
Facile ;)
Cas 1 :
$ grep bidule /etc/group # à utiliser avec awk pour virer le login des autres utilisateurs si # besoin est.
Oui mais tu vas répondre à ton boss ? : - grpAcces123 - grpAcces124 - GRPSpecial124BX42 - groupAuth15 ...
Non, ce qu'il veut, c'est une liste de répertoires auxquels a accès l'utilisateur.
Négatif, car l'accès à un sous-répertoire peut dépendre des accès des répertoires parents, et ton répertoire peut être enterré sous trente tonnes de répertoires parents, avec une arborescence amazonnienne (2 ou trois 'n' ? j'oublie toujours), donc la seule observation de *ce* répertoire ne suffit pas.
********
Je ne vous parle même pas du fait que pour des utilisateurs qui assignent ces droits (responsables hiérarchiques en entreprise), il vaudrait mieux mapper les noms de répertoires avec des noms en clair (cpta_42 => Dossiers de comptabilité 2003)...
Bref, je ne vois qu'un moyen pour l'instant, ça serait de disposer de deux matrices : - une matrice qui mappe une liste de groupes sur une arborescence (donc sans doute du genre mtree) - une matrice qui mappe une liste d'utilisateurs sur une liste de groupes (donc du genre /etc/group) sauf que : * tout cela doit être décrit dans un gros fichier de config, plus un script kivabien * le nombre de groupes va exploser, d'où ma question sur le nombre max de groupes
Thomas -- Ta mère elle cherche un micro-dénoyauteur.
Exact ! Comment le sais-tu ?
-- Nicolas Ecarnot
Le 29 Oct 2003 14:58:44 GMT,
Thomas Nemeth <thomas@exether.vipere.noire> disait :
Le mer 29 oct 2003 à 15:54, Nicolas Ecarnot a tapoté :
|
| Imagine que tu gères un serveur de fichiers, avec des centaines
| d'utilisateurs, et plusieurs centaines de milliers de fichiers.
| Imagine que pendant des années tu as définis des droits, des accès, des
| particularités selon les utilisateurs qui te demande tel ou tel accès à
| tel ou tel sous-répertoire.
|
| Un jour, ton boss te demande un compte-rendu pour connaître la liste
| complète des accès de Monsieur Bidule, ou à l'inverse, connaître la
| liste des utilisateurs qui accèdent à tel sous-répertoire.
|
| Comment-fais tu ?
Facile ;)
Cas 1 :
$ grep bidule /etc/group
# à utiliser avec awk pour virer le login des autres utilisateurs si
# besoin est.
Oui mais tu vas répondre à ton boss ? :
- grpAcces123
- grpAcces124
- GRPSpecial124BX42
- groupAuth15
...
Non, ce qu'il veut, c'est une liste de répertoires auxquels a accès
l'utilisateur.
Négatif, car l'accès à un sous-répertoire peut dépendre des accès des
répertoires parents, et ton répertoire peut être enterré sous trente
tonnes de répertoires parents, avec une arborescence amazonnienne (2 ou
trois 'n' ? j'oublie toujours), donc la seule observation de *ce*
répertoire ne suffit pas.
********
Je ne vous parle même pas du fait que pour des utilisateurs qui
assignent ces droits (responsables hiérarchiques en entreprise), il
vaudrait mieux mapper les noms de répertoires avec des noms en clair
(cpta_42 => Dossiers de comptabilité 2003)...
Bref, je ne vois qu'un moyen pour l'instant, ça serait de disposer de
deux matrices :
- une matrice qui mappe une liste de groupes sur une arborescence
(donc sans doute du genre mtree)
- une matrice qui mappe une liste d'utilisateurs sur une liste de
groupes (donc du genre /etc/group) sauf que :
* tout cela doit être décrit dans un gros fichier de config, plus un
script kivabien
* le nombre de groupes va exploser, d'où ma question sur le nombre max
de groupes
Thomas
--
Ta mère elle cherche un micro-dénoyauteur.
Le 29 Oct 2003 14:58:44 GMT, Thomas Nemeth disait :
Le mer 29 oct 2003 à 15:54, Nicolas Ecarnot a tapoté : | | Imagine que tu gères un serveur de fichiers, avec des centaines | d'utilisateurs, et plusieurs centaines de milliers de fichiers. | Imagine que pendant des années tu as définis des droits, des accès, des | particularités selon les utilisateurs qui te demande tel ou tel accès à | tel ou tel sous-répertoire. | | Un jour, ton boss te demande un compte-rendu pour connaître la liste | complète des accès de Monsieur Bidule, ou à l'inverse, connaître la | liste des utilisateurs qui accèdent à tel sous-répertoire. | | Comment-fais tu ?
Facile ;)
Cas 1 :
$ grep bidule /etc/group # à utiliser avec awk pour virer le login des autres utilisateurs si # besoin est.
Oui mais tu vas répondre à ton boss ? : - grpAcces123 - grpAcces124 - GRPSpecial124BX42 - groupAuth15 ...
Non, ce qu'il veut, c'est une liste de répertoires auxquels a accès l'utilisateur.
Négatif, car l'accès à un sous-répertoire peut dépendre des accès des répertoires parents, et ton répertoire peut être enterré sous trente tonnes de répertoires parents, avec une arborescence amazonnienne (2 ou trois 'n' ? j'oublie toujours), donc la seule observation de *ce* répertoire ne suffit pas.
********
Je ne vous parle même pas du fait que pour des utilisateurs qui assignent ces droits (responsables hiérarchiques en entreprise), il vaudrait mieux mapper les noms de répertoires avec des noms en clair (cpta_42 => Dossiers de comptabilité 2003)...
Bref, je ne vois qu'un moyen pour l'instant, ça serait de disposer de deux matrices : - une matrice qui mappe une liste de groupes sur une arborescence (donc sans doute du genre mtree) - une matrice qui mappe une liste d'utilisateurs sur une liste de groupes (donc du genre /etc/group) sauf que : * tout cela doit être décrit dans un gros fichier de config, plus un script kivabien * le nombre de groupes va exploser, d'où ma question sur le nombre max de groupes
Thomas -- Ta mère elle cherche un micro-dénoyauteur.
Exact ! Comment le sais-tu ?
-- Nicolas Ecarnot
Thomas Nemeth
Le mer 29 oct 2003 à 16:39, Nicolas Ecarnot a tapoté : | Le 29 Oct 2003 14:58:44 GMT, | Thomas Nemeth disait : | > Le mer 29 oct 2003 à 15:54, Nicolas Ecarnot a tapoté : | >| | >| Un jour, ton boss te demande un compte-rendu pour connaître la liste | >| complète des accès de Monsieur Bidule, ou à l'inverse, connaître la | >| liste des utilisateurs qui accèdent à tel sous-répertoire. | >| | >| Comment-fais tu ? | > | > Facile ;) | > | > Cas 1 : | > | > $ grep bidule /etc/group | > # à utiliser avec awk pour virer le login des autres utilisateurs si | > # besoin est. | | Oui mais tu vas répondre à ton boss ? : | - grpAcces123 | - grpAcces124 | - GRPSpecial124BX42 | - groupAuth15 | ... | | Non, ce qu'il veut, c'est une liste de répertoires auxquels a accès | l'utilisateur.
Aaahhh... Bin... find ;)
| > Cas 2 : | > | > groupe=`ls -ld sous/répertoire | awk '{print $3}'` | > grep "^$groupe" /etc/group | | Négatif, car l'accès à un sous-répertoire peut dépendre des accès des | répertoires parents, et ton répertoire peut être enterré sous trente | tonnes de répertoires parents, avec une arborescence amazonnienne (2 ou | trois 'n' ? j'oublie toujours), donc la seule observation de *ce* | répertoire ne suffit pas.
'tain mais c'est le bordel chez toi ! :)
| > Thomas | > -- | > Ta mère elle cherche un micro-dénoyauteur. | | Exact ! Comment le sais-tu ?
Chais pas : elle a installé Hurd ;) ?
Thomas -- Ta mère elle choisi Linux à cause du cadeau-surprise.
Le mer 29 oct 2003 à 16:39, Nicolas Ecarnot a tapoté :
| Le 29 Oct 2003 14:58:44 GMT,
| Thomas Nemeth <thomas@exether.vipere.noire> disait :
| > Le mer 29 oct 2003 à 15:54, Nicolas Ecarnot a tapoté :
| >|
| >| Un jour, ton boss te demande un compte-rendu pour connaître la liste
| >| complète des accès de Monsieur Bidule, ou à l'inverse, connaître la
| >| liste des utilisateurs qui accèdent à tel sous-répertoire.
| >|
| >| Comment-fais tu ?
| >
| > Facile ;)
| >
| > Cas 1 :
| >
| > $ grep bidule /etc/group
| > # à utiliser avec awk pour virer le login des autres utilisateurs si
| > # besoin est.
|
| Oui mais tu vas répondre à ton boss ? :
| - grpAcces123
| - grpAcces124
| - GRPSpecial124BX42
| - groupAuth15
| ...
|
| Non, ce qu'il veut, c'est une liste de répertoires auxquels a accès
| l'utilisateur.
Aaahhh... Bin... find ;)
| > Cas 2 :
| >
| > groupe=`ls -ld sous/répertoire | awk '{print $3}'`
| > grep "^$groupe" /etc/group
|
| Négatif, car l'accès à un sous-répertoire peut dépendre des accès des
| répertoires parents, et ton répertoire peut être enterré sous trente
| tonnes de répertoires parents, avec une arborescence amazonnienne (2 ou
| trois 'n' ? j'oublie toujours), donc la seule observation de *ce*
| répertoire ne suffit pas.
'tain mais c'est le bordel chez toi ! :)
| > Thomas
| > --
| > Ta mère elle cherche un micro-dénoyauteur.
|
| Exact ! Comment le sais-tu ?
Chais pas : elle a installé Hurd ;) ?
Thomas
--
Ta mère elle choisi Linux à cause du cadeau-surprise.
Le mer 29 oct 2003 à 16:39, Nicolas Ecarnot a tapoté : | Le 29 Oct 2003 14:58:44 GMT, | Thomas Nemeth disait : | > Le mer 29 oct 2003 à 15:54, Nicolas Ecarnot a tapoté : | >| | >| Un jour, ton boss te demande un compte-rendu pour connaître la liste | >| complète des accès de Monsieur Bidule, ou à l'inverse, connaître la | >| liste des utilisateurs qui accèdent à tel sous-répertoire. | >| | >| Comment-fais tu ? | > | > Facile ;) | > | > Cas 1 : | > | > $ grep bidule /etc/group | > # à utiliser avec awk pour virer le login des autres utilisateurs si | > # besoin est. | | Oui mais tu vas répondre à ton boss ? : | - grpAcces123 | - grpAcces124 | - GRPSpecial124BX42 | - groupAuth15 | ... | | Non, ce qu'il veut, c'est une liste de répertoires auxquels a accès | l'utilisateur.
Aaahhh... Bin... find ;)
| > Cas 2 : | > | > groupe=`ls -ld sous/répertoire | awk '{print $3}'` | > grep "^$groupe" /etc/group | | Négatif, car l'accès à un sous-répertoire peut dépendre des accès des | répertoires parents, et ton répertoire peut être enterré sous trente | tonnes de répertoires parents, avec une arborescence amazonnienne (2 ou | trois 'n' ? j'oublie toujours), donc la seule observation de *ce* | répertoire ne suffit pas.
'tain mais c'est le bordel chez toi ! :)
| > Thomas | > -- | > Ta mère elle cherche un micro-dénoyauteur. | | Exact ! Comment le sais-tu ?
Chais pas : elle a installé Hurd ;) ?
Thomas -- Ta mère elle choisi Linux à cause du cadeau-surprise.
F. Senault
On 29 Oct 2003 15:39:28 GMT, Nicolas Ecarnot wrote:
Négatif, car l'accès à un sous-répertoire peut dépendre des accès des répertoires parents, et ton répertoire peut être enterré sous trente tonnes de répertoires parents, avec une arborescence amazonnienne (2 ou trois 'n' ? j'oublie toujours), donc la seule observation de *ce* répertoire ne suffit pas.
Pourquoi ne pas assumer la position de l'utilisateur et laisser l'OS donner ce qu'il peut ; par exemple :
su user -c 'find /racine -type d' | ...
Et un grep/perl si nécéssaire ?
(C'est un poil barbare, mais au moins, ça reflète exactement comment ça va se passer ; un ou deux paramètres en plus sur le find vont permettre de préciser, par exemple le -perm...)
* le nombre de groupes va exploser, d'où ma question sur le nombre max de groupes
Ca, c'est une autre question, évidemment.
Fred -- While preceding your entrance with a grenade is a good tactic in Quake, it can lead to problems if attempted at work. (Cris Hacking in the SDM)
On 29 Oct 2003 15:39:28 GMT, Nicolas Ecarnot wrote:
Négatif, car l'accès à un sous-répertoire peut dépendre des accès des
répertoires parents, et ton répertoire peut être enterré sous trente
tonnes de répertoires parents, avec une arborescence amazonnienne (2 ou
trois 'n' ? j'oublie toujours), donc la seule observation de *ce*
répertoire ne suffit pas.
Pourquoi ne pas assumer la position de l'utilisateur et laisser l'OS
donner ce qu'il peut ; par exemple :
su user -c 'find /racine -type d' | ...
Et un grep/perl si nécéssaire ?
(C'est un poil barbare, mais au moins, ça reflète exactement comment ça
va se passer ; un ou deux paramètres en plus sur le find vont permettre
de préciser, par exemple le -perm...)
* le nombre de groupes va exploser, d'où ma question sur le nombre max
de groupes
Ca, c'est une autre question, évidemment.
Fred
--
While preceding your entrance with a grenade is a good tactic in
Quake, it can lead to problems if attempted at work.
(Cris Hacking in the SDM)
Négatif, car l'accès à un sous-répertoire peut dépendre des accès des répertoires parents, et ton répertoire peut être enterré sous trente tonnes de répertoires parents, avec une arborescence amazonnienne (2 ou trois 'n' ? j'oublie toujours), donc la seule observation de *ce* répertoire ne suffit pas.
Pourquoi ne pas assumer la position de l'utilisateur et laisser l'OS donner ce qu'il peut ; par exemple :
su user -c 'find /racine -type d' | ...
Et un grep/perl si nécéssaire ?
(C'est un poil barbare, mais au moins, ça reflète exactement comment ça va se passer ; un ou deux paramètres en plus sur le find vont permettre de préciser, par exemple le -perm...)
* le nombre de groupes va exploser, d'où ma question sur le nombre max de groupes
Ca, c'est une autre question, évidemment.
Fred -- While preceding your entrance with a grenade is a good tactic in Quake, it can lead to problems if attempted at work. (Cris Hacking in the SDM)
