Bonjour bon voila ce que je comprends:

Le sticky bit

        Ce droit réservé à root s'applique à un répertoire et corrige une bizzarerie du système. Par defaut, un répertoire accessible en écriture à un ensemble d(utilisateurs permet à l'un d'entre eux de détruire les fichiers d'un autre utilisateur. Avec le "sticky bit" il faut etre propriétaire d'un fichier pour avoir le droit de le détruire.

Les droits d'endossement (SUID, SGID) pour un exécutable

       Le principe des droits d'endossement est d'augmenter les privilèges des utilisateurs. Par exemple, le droit set-UID (SUID) sur un binaire exécutable permet à l'utilisateur de l'application correspondante d'avoir les mêmes droits d'accés que le propriétaire du binaire.
Le droit Set-GID (SGID) permet lui d'endosser les droits du groupe auquel est affilié le binaire.

Exemple: le fichier etc/shadow n'est en théorie accéssible qu'à root. Or tout utilisateur a accés en écriture à ce fichier lorsqu'il change son mot de passe grâce à la commande /usr/bin/passwd. l'explication réside dans le fait que cette commande, possédée par root posséde le droit SUID et donne de fait à tous à tous les utilisateurs les mêmes droits que root.

Le droit SGID pour un répertoire.

       Lorsque l'on crée un fichier il est automatiquement affilié à son groupe courant, qui est par defaut son groupe principal. Si l'on crée un fichier dans un répertoire qui posséde le droit SGID, son groupe sera identique à celui du répertoire. La conséquence c'est que l'ensemble des fichiers du répertoire appartiendra au même groupe, ce qui est intéressant pour un répertoire accésible à plusieurs personnes.

Maintenant je vais tester Le droit SGID sur certain de mes répertoires... je n'ai jamais fait es qu'il y a une option pour mysecureshell ou faut il que je gére ça au niveau du systéme lui même (file systéme)?...

Vu sur: http://www.linux-france.org/article/sys … ers-3.html

Merci pour la réponse ultra rapide j'ai répondu moins vite car ça fait pédaler ces droits....

Salut,

bon je ne m'en sort pas de ces histoires de droits que ce sois au niveau systéme ou au niveau de mysecureshell....

Le vrai problème c'est l'héritage des droits par défault sur les fichiers et/ou les répertoires créés je vais tenter d'être le plus explicite possible :-)

Voici le sftp_config:

<Default>
GlobalDownload 10m
Home /home
VirtualChroot true
IgnoreHidden true
Charset "iso-8859-1"
IdleTimeOut 50m
CanChangeTime false

CanChangeRights false
HideFiles "^(lost\+found|www)$"
LogFile /var/log/sftp/global.log
MaxOpenFilesForUser 12
MaxReadFilesForUser 12
MaxWriteFilesForUser 12
</Default>

<Group sftpbois>
LogFile /sftp/sftp_bois.log
DefaultRights 0775 0775
Download 1m
Upload 0
StayAtHome true
VirtualChroot true
LimitConnection 60
LimitConnectionByIP 10
</Group>

<User agioo>
LogFile /var/log/sftp/agioo.log
HideFiles "^(lost\+found|fredcol|lapom|cemoi|jmcussous|lolobenas|test|munin)$"
</User>

<User jmcussous>
LogFile /var/log/sftp/jmcussous.log
HideFiles "^(lost\+found|fredcol|lapom|cemoi|agioo|lolobenas|test|munin)$"
</User>

<User lolobenas>
LogFile /var/log/sftp/lolobenas.log
HideFiles "^(lost\+found|fredcol|lapom|cemoi|jmcussous|agioo|test|munin)$"
</User>

<User fredcol>
LogFile /var/log/sftp/fredcol.log
HideFiles "^(lost\+found|agioo|lapom|cemoi|jmcussous|lolobenas|test|munin)$"
</User>

<User lapom>
LogFile /var/log/sftp/lapom.log
HideFiles "^(lost\+found|fredcol|agioo|cemoi|jmcussous|lolobenas|test|munin)$"
</User>

ici j'ai fonctionner par exclusion (mais par désespoir car je n'arrive pas à aboutir à ce que je veux) en gros je cache le répertoire des autres utilisateurs pour en éviter l'accé. J'ai mis le droits par default en 0775 pour l'utilisateur et 0775 pour le groupe. Dans la logique ça devrai rouler comme ça si ne me trompe pas mais en fait non...

coté systéme voila se que donne l'arboressence:

ls -l
total 52
drwxr-xr-x 2 agioo     sftpbois  4096 mai 15 20:29 agioo
drwxr-xr-x 3 cemoi     cemoi     4096 mai  6 19:40 cemoi
drwxr-xr-x 2 fredcol   sftpbois  4096 mai  3 09:58 fredcol
drwxr-xr-x 2 jmcussous sftpbois  4096 mai  3 11:53 jmcussous
drwxr-xr-x 3 lapom     sftpbois  4096 mai  8 10:50 lapom
drwxr-xr-x 2 lolobenas sftpbois  4096 mai  3 10:00 lolobenas
drwx------ 2 root      root     16384 mai  1 14:59 lost+found
lrwxrwxrwx 1 root      root        13 mai  8 11:12 munin -> var/www/munin
drwxrwxr-x 3 agioo     sftpbois  4096 mai 15 20:23 partage
drwxrwxr-x 3 agioo     sftpbois  4096 mai  8 10:39 test
drwxr-xr-x 3 www-data  www-data  4096 mai  8 11:21 www

Dans un premier temps je voudrai que tout ce qui est créé dans le répertoire partage ai les droits permettant le lecture/ecriture/execution (rwx) pour l'utilisateur qui a créé le repertoire ou le fichier et les mêmes droits pour le group ce qui permettra à chaque utilisateur appartenant à ce group d'avoir les mêmes droits que l'utilisateur qui a fait la création.

Avec la sftp_config tel qu'il est ça marche ... mais comment obtenir le même comportement au niveau systéme?... (j'aimerai éviter les acl)

Bonjour,

d'après la phrase suivante...

...MSS gère aussi les droits étendus ? Or ce n'est pas ce que j'observe : si je crée un répertoire avec le bit SGID,
tous les répertoires créés à l'intérieur devraient hériter de ce SGID (je cite wikipedia) :

et c'est bien ce que j'obtiens en ligne de commande, mais pas à travers MSS.
Serait-ce un problème de réglage du genre DefaultRights ?

À ce propos je ne comprends pas bien la documentation sur MinimumRights :

Pour un fichier nouvellement créé, c'est DefaultRights qui s'applique, non ?

Merci d'avance.

Toujours aussi rapide pour réagir ! Chapeau et merci.

Absolument !

Et cette nouvelle version, est-elle prévue prochainement ?
Sinon, à défaut, y aurait-il moyen d'avoir un patch en attendant ?

bonjour,
es que ce patch est appliqué dans la dernière version de My Secure Shell?

Merci pour votre travail 

ok merci!

Comment fait on pour appliquer ce patch sur la 1.15?

Quand es que sortira la 1.20? (à la louche)

Merci :=)