Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 06/12/2018, à 21:06

stylik

héritage de permissions

Bonsoir,

Les droits Posix permettent d'attribuer des permissions en lecture-écriture-exécution aux fichiers aux utilisateurs PGO.

Un fichier avec des P étendues est limité par les P de son répertoire parent.

Existe-t-il un moyen autre que le masque utilisateur pour que les P du fichier soient automatiquement alignées sur celles du répertoire parent à sa création ?


MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne

#2 Le 06/12/2018, à 21:45

inbox

Re : héritage de permissions

Salut,

Tu peux utiliser les ACLhttps://doc.ubuntu-fr.org/acl pour une gestion des droits plus fine.

A+


Un problème résolu ? Indiquez le en modifiant le titre du sujet.

Hors ligne

#3 Le 06/12/2018, à 23:53

stylik

Re : héritage de permissions

Je connais un peu mais je vais creuser le sujet

Merci

Dernière modification par stylik (Le 06/12/2018, à 23:53)


MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne

#4 Le 07/12/2018, à 01:40

Coeur Noir

Re : héritage de permissions

Complexe les ACL non ?

setgid : https://fr.wikipedia.org/wiki/Setuid

À priori c'est sgid qui te concerne : « si cette propriété est appliquée à un répertoire, tout fichier ou sous-répertoire créé dans ce répertoire parent appartiendra au groupe de celui-ci et non au groupe de l'utilisateur qui crée l'élément. Ceci est utile par exemple dans un dossier de partage, où l'on souhaite que tous les membres d'un groupe de superviseurs puissent modifier ou supprimer les contributions des membres d'un autre groupe. »

J'écris à priori car je ne sais pas ce que tu veux faire, ni ne comprends ce que tu entends par Un fichier avec des P étendues ? P pour permissions ? Propriétaires ? Ça a l'air de rien mais il vaut mieux utiliser le même langage partout ;-) quand on touche à l'administration :

  • les droits sont r pour read w pour write x pour execute

  • les propriétaires sont u et g pour user et group

  • tous ceux qui ne sont pas le premier ( utilisateur ) et ne font pas partie du second ( groupe ) ce sont les autres, o pour other.

PGO → je ne sais pas deviner.

Au cas où : attention, ces permissions spéciales sont à manier avec précaution et en toute connaissance de cause. C'est évoqué dans le lien ci-dessus, ou celui-là : https://docs.oracle.com/cd/E19683-01/81 … index.html
Donc au préalable, être à l'aise avec droits et permissions, entre autres.


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#5 Le 07/12/2018, à 21:28

stylik

Re : héritage de permissions

" utilisateurs PGO " = maldonne (un mauvais franglais)

Désolé c'était " utilisateurs PGA " (propriétaire-groupe-autres) qu'il fallait deviner.

P étendues = permissions étendues

Je viens d'aligner les P des répertoires et fichiers sur le système de fichier (syf) qui me sert de stockage.
Elles sont à présent toutes en 700/600.
Je m'interroge sur les moyens de conserver cet alignement.

Il y a plusieurs points à considérer :

  • l'arborescence des droits POSIX (les P du répertoire supérieur l'emportent sur celles du répertoire/fichier inférieur) – à confirmer

  • les masques utilisateurs ($ ou #) par défaut

  • parfois l'option masque d'un syf exotique (umask-fmask-dmask pour FAT, FUSE etc)

Q1 – Se peut-il que des P soient attribuées par défaut à des fichiers nouveaux indépendamment de ces trois considérations ?

Q2 – Ma question était la suivante : peut-on aligner par défaut les P d'un fichier sur celles du dossier qui le contient ?
Je voudrais que les P du propriétaire d'un dossier s'applique à toute l'arborescence des sous-dossiers et aux fichiers.
C'est le meilleur moyen de conserver l'alignement. C'est pourquoi je parle d'héritage.

Le sgid permet d'aligner le groupe du fichier sur celui du dossier.
L'ennui en ce qui me concerne c'est que les G n'ont aucun droit. Donc ça ne répond pas vraiment à ma préoccupation.


Si à la question 1 vous me dites qu'il n'existe pas d'autres moyens de gérer les P, alors je sais ce qu'il me reste à faire …
inbox m'a aiguillé sur les ACL et j'ai repéré un moyen de « définir l'accès en lecture par défaut pour "utilisateur" pour les nouveaux fichiers créés dans "dossier ».

setfacl -m d:u:utilisateur:r dossier.

Il faut que je le teste.


MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne

#6 Le 08/12/2018, à 01:17

Coeur Noir

Re : héritage de permissions

Non il ne faut pas que tu testes les ACL.

Il faut d'abord comprendre les droits et permissions de base, puis voir de quoi tu as besoin.
Es-tu dans un contexte multi-utilisateurs ?
Le but c'est quoi : avoir un espace de stockage commun accessible à plusieurs utilisateurs en permanence ?

Le propriétaire c'est l'utilisateur qui crée le fichier. Donc si tu es dans la session raoul, les fichiers créés appartiendront à raoul.
S'il n'y a qu'un seul utilisateur pas besoin d'aller plus loin en terme d'administration.

Maintenant si raoul seul utilisateur n'arrive pas à écrire à un certain endroit ( le point de montage d'une partition de disque par exemple ? ) ça peut relever d'un problèmes de droits à régler au niveau du montage de cette partition ( les options varient en fonction des systèmes de fichiers, tous ne gèrent pas les permissions unix posix ).

Donc Q1 → Possible mais absolument pas souhaitable.
La situation normale c'est : l'utilisateur qui crée un fichier en est le propriétaire. C'est sain.
Autrement c'est la porte ouverte à des élévations de privilège. Dangereux.

Q2 → Pas besoin d'héritage. Ni d'acl ni de suid ou sgid ( tu n'as donc pas lu les liens proposés ? ).
Juste les droits nécessaires à l'endroit opportun pour tel utilisateur. Simple. Sûr.
Par exemple : ton répertoire personnel /home/toi quand tu es dans la session toi. Ce dossier /home/toi t'appartient, tu as donc les droits rwx dessus. Et surtout toi seul uniquement a le droit d'y écrire.
Maintenant si tu veux enregistrer des fichiers que tu crées depuis ta session toi, ailleurs que dans ton répertoire perso, il faut t'assurer que tu as les droits nécessaires sur cette autre destination : toujours pas besoin ni d'acl, ni suid ou sgid.

J'ai l'impression - avec ce que je crois comprendre de tes intentions - que la solution est à chercher du côté du §3 de cette doc' https://doc.ubuntu-fr.org/mount_fstab
Ou alors décris de façon plus simple / pragmatique ce que tu souhaites faire, d'un point de vue humain et pas informatique.



____________________hors sujet je pense mais comme j'avais commencé par ça_____________________________

Par défaut sous Ubuntu :

  • quand on crée un utilisateur, il se crée un groupe du nom de cet utilisateur.

  • l'utilisateur a les droits rwx, le groupe rx et les autres rx
    ( relire doc's suggérées au #4 concernant les droits et la nuance entre x et X, exécution sur dossier et fichiers )

Ces comportement sont réglés par le fichier /etc/login.defs
…sauf sous gnome, où le réglage de l'umask global n'est pas au point depuis des années.

Un groupe - comme son nom l'indique - c'est un ensemble d'utilisateurs. Et un utilisateur peut faire partie de divers groupes. Tous les membres d'un group ont donc les droits de ce groupe.

À toi de gérer ça comme tu l'entends : créer des groupes ( travail, maison, enfants, etc… ) y mettre dedans tel et tels utilisateurs, ajouter le droit d'écriture aux groupes, éventuellement mettre le bit sgid sur tel dossier ( où tu souhaites que tout fichier nouvellement créé hérite du groupe propriétaire de ce dossier ) etc, etc…
Exemple :

  • un système où existent les utilisateurs papa, maman, papy, mamy, fils, fille.

  • des dossiers configurés en 770 rwxrwx---

  • papa, maman, papy, mamy font partie du groupe maison

  • papa, maman font partie du groupe travail

  • papa, maman, fils, fille font partie du groupe enfants
    → papa, maman pourront lire et écrire dans des dossiers appartenant aux 3 groupes
    → seuls papa et maman lisent et écrivent dans des dossiers appartenant au groupe travail
    → fils et fille peuvent lire écrire dans des dossiers appartenant à leur groupe mais dans aucun dossier d'un autre groupe

Dernière modification par Coeur Noir (Le 08/12/2018, à 01:29)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#7 Le 08/12/2018, à 10:13

bruno

Re : héritage de permissions

Bonjour,

Je ne peux qu'approuver ce que dit Cœur Noir.

Je précise tout de me qu'il n'y a pas de notion d'héritage dans les droits UNIX (ni «d'arborescence des droits») et que certains systèmes de fichiers (FAT par exemple) ne prennent pas en charge ces droits.

Maintenant il faudrait nous expliquer précisément pourquoi tu as ce besoin et surtout éviter d'utiliser des abréviations qui te sont propres et qui rendent la compréhension de tes massages assez difficile.

Hors ligne

#8 Le 08/12/2018, à 12:23

stylik

Re : héritage de permissions

Non je n'avais pas lu la doc Oracle.
Je viens de la consulter et je constate que les P spéciales setuid-setgid et stickbit concernent les fichiers exécutables.
Dans mon cas il s'agit de fichiers bureautiques. Les permissions sont

  • 700 pour les dossiers, soit lecture-écriture-exécution pour le propriétaire (je ne connais que moi sur cet ordi)

  • 600 pour les fichiers, soit lecture-écriture pour le propriétaire (je ne connais que moi sur cet ordi)


Je ne comptais pas :

  • déroger à la règle « l'utilisateur qui crée un fichier en est le propriétaire.»

  • exécuter un programme avec l’identifiant du propriétaire du fichier (setuid) ou avec l’identifiant de groupe propriétaire du fichier (setgid)

  • positionner des bit collant sur les répertoires pour enlève la suppression au droit d'écriture


Mon propos était juste de m'assurer que les 3 considérations évoquées plus haut (POSIX + ACL, masques par défaut des utilisateurs, masques en option de montage des système de fichiers) il n'y ait rien d'autre qui agisse sur les droits par défaut.
J'aimerais que les fichiers soient créés par défauts en 700/600.

Pour placer un masque par défaut c'est le fichier /etc/login.defs qu'il faut configurer.

# gedit /etc/login.defs 

(…) 
# Login configuration initializations: 
# 
#	ERASECHAR	Terminal ERASE character ('\010' = backspace). 
#	KILLCHAR	Terminal KILL character ('\025' = CTRL/U). 
#	UMASK		Default "umask" value. 				
# 
# The ERASECHAR and KILLCHAR are used only on System V machines. 
# 
# UMASK is the default umask value for pam_umask and is used by 
# useradd and newusers to set the mode of the new home directories. 
# 022 is the "historical" value in Debian for UMASK 
# 027, or even 077, could be considered better for privacy 
# There is no One True Answer here : each sysadmin must make up his/her 
# mind. 
#

pam.umask est un module
# dpkg -S pam_umask
libpam-modules: /lib/x86_64-linux-gnu/security/pam_umask.so
libpam-modules: /usr/share/man/man8/pam_umask.8.gz

Deux questions :

Q1 : dans /etc/login.defs,  est-ce la valeur  Default "umask" value  qu'il faut  remplacer par 077 (pour avoir des droits 700 sur les dossiers et 600 sur les fichiers) ?
Q2 : est-ce un masque  pour root # ou un masque pour l'utilisateur $ ?

Dernière modification par stylik (Le 08/12/2018, à 15:46)


MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne

#9 Le 08/12/2018, à 15:45

Coeur Noir

Re : héritage de permissions

Q3 → oui c'est bien là. Mais tiens compte de ces 2 avertissements :

  1. c'est un réglage système global ! Dès lors tout nouvel utilisateur créé sur ton système se verra attribuer ces droits… 077 c'est très restrictif mais pourquoi pas.

  2. si tu es sous l'environnement Gnome ( et donc l'environnement par défaut d'Ubuntu depuis 17.10 ) il y a d'autres fichiers de configuration à modifier pour assurer la « globalité » d'umask ( gnome n'utilise pas - ou mal - pam_umask )
    Sous Unity, LXDE et Budgie je sais d'expérience que cela fonctionne avec la modif' de umask dans /etc/login.defs que je passe à 002 plutôt que 022 car je gère plusieurs utilisateurs et groupes sur les machines que j'administre.

je constate que les P spéciales setuid-setgid et stickbit concernent les fichiers exécutables.
→ ton usage de « P » ( propriétés ? permissions ? propriétaire ? ) suggère potentiellement que tu n'as pas les idées claires sur ce que sont les droits / permissions.
Tu as peut-être les idées tout à fait claires, hein, mais du coup pour nous qui ne sommes pas dans ta tête, te lire c'est confus.
→ et non ça ne concerne pas que les fichiers exécutables. Par contre il faut redoubler de prudence si appliqué à des fichiers exécutables particulièrement en cas d'usage du bit suid…
Pour rappel : un dossier est un fichier exécutable, par exemple. Sans droit d’exécution, un dossier ne peut pas être « traversé / ouvert ». Relire #4 ou #6, x et X, droits…

Est-ce que j'ai bien compris ?

  • tu sembles vouloir créer un espace de stockage auquel seul un utilisateur aura accès en lecture et écriture,

  • tu sembles vouloir que tout fichier/dossier mis dans cet espace se voit attribuer rwX--------- soit lecture, écriture, exécution pour les dossiers, uniquement pour l'utilisateur propriétaire, absolument rien pour les autres,

  • s'agit-il bien d'un espace situé sur un système de fichiers compatible unix ?
    → si c'est bien ça et encore une fois, avec les réglages par défaut d'Ubuntu, il s'agira seulement d'appliquer les « bons » droits sur UN dossier - le dossier racine de ton stockage - pas besoin de modifier le umask global, l'utilisation du bit sgid suffira, sur ce dossier.

Dernière modification par Coeur Noir (Le 08/12/2018, à 16:06)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#10 Le 08/12/2018, à 15:50

Coeur Noir

Re : héritage de permissions

bruno a écrit :

Maintenant il faudrait nous expliquer précisément pourquoi tu as ce besoin et surtout éviter d'utiliser des abréviations qui te sont propres et qui rendent la compréhension de tes massages assez difficile.

Hi, hi ;-) tu es kiné ?


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#11 Le 08/12/2018, à 16:11

stylik

Re : héritage de permissions

Tu as bien compris : un seul utilisateur avec tous les droits (rien pour les groupe et les autres). Le système de fichier est en reiserfs.

Tu préconises de placer le dossier racine en 700. Il s'agit du point de montage sdb2. La partition entière est dédiée au stockage de mes documents.

$ ll /media/sdb2/
total 5
drwx------ 11 stylik root     272 janv.  1  2017 ./
drwxr-xr-x  8 root    root    4096 déc.   8 14:51 ../

Je peux éventuellement placer un bit sgid sur ce dossier mais il faudra auparavant que je change le groupe (actuellement root). Ainsi les fichiers situés à l'intérieur et les sous-répertoires hériterons du groupe propriétaire de ce dossier. C'est un filtre pour les utilisateurs. Les modes des fichiers ne seront pas forcément identiques dans ce cas … (si j'ai bien compris)


MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne

#12 Le 08/12/2018, à 17:16

stylik

Re : héritage de permissions

Pour tester le fichier /etc/login.defs (histoire de …) j'y ai placé un UMASK de 077 en remplacement de rien.

# nano /etc/login.defs

# Login configuration initializations:
#
#       ERASECHAR       Terminal ERASE character ('\010' = backspace).
#       KILLCHAR        Terminal KILL character ('\025' = CTRL/U).
UMASK           0077
#
# The ERASECHAR and KILLCHAR are used only on System V machines.
#
# UMASK is the default umask value for pam_umask and is used by
# useradd and newusers to set the mode of the new home directories.

L'umask de $ est passé de 0002 à 0007.
Je m'attendais à 0077.

J'ai créé un fichier :

$ touch masque

$ ll !$
ll masque
-rw-rw---- 1 stylik stylik 0 déc.   8 16:50 masque
				

Cela vous paraît-il normal ?


MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne

#13 Le 08/12/2018, à 17:44

Coeur Noir

Re : héritage de permissions

Tu as vraiment besoin de ReiserFS ? Il gère les droits, cela dit.

Je ne comprends pas bien pourquoi tu veux « supprimer » les droits de groupe dans ton histoire. Si le groupe c'est stylik, bah seul stylik y accède… ou d'autres utilisateurs mais seulement si tu les ajoutes au groupe stylik…
Car par défaut sous Ubuntu les fichiers sont créés avec comme groupe propriétaire, le même groupe que l'utilisateur propriétaire. C'est justement orienté utilisateur unique. On change ça quand on a un contexte multi-utilisateurs et qu'on veut organiser finement des partages de données entre divers utilisateurs et groupes.

Donc oui tu peux désigner stylik comme groupe propriétaire. Attribuer les droits rwX à ce groupe, puis le bit s au groupe. Si tu appliques ça à /media/sdb2 effectivement c'est tout ce montage qui fonctionnera comme ça.
( et attention, ce qui est déjà dans sdb2 ne sera pas impacté, pour les fichiers/dossiers déjà présents il faudra réajuster leurs propriétaires - u et g - et permissions de g. )
Il faudrait par ailleurs vérifier comment est effectué ce montage via cat /etc/fstab des fois qu'il comporterait une option contradictoire.

Je te conseillerais plutôt de créer un nouveau dossier vide dans sdb2, et uniquement à ce dossier appliquer la « recette »…
Dès lors tout ce qui sera placé dans ce dossier donnera à l'utilisateur les mêmes droits que le groupe ( propriétaire du dossier ). Ça ne change pas l'utilisateur propriétaire des fichiers, seulement ses droits.
Et comme l'utilisateur c'est stylik et le groupe stylik aussi ( avec les droits rwX ) seul stylik a tous les droits là-dedans. Aucun autre utilisateur ne peut y écrire, y être propriétaire de quoi que ce soit.

par conséquent, dans le fond y a même pas besoin du bit s sur g tant que tu es le seul utilisateur ! Le fonctionnement par défaut d'Ubuntu suffit… Ça peut être différent sous d'autres distributions. On peut avoir besoin d'autres choses selon le contexte. Mais si le but c'est que stylik soit seul maître à bord, tu n'as besoin de rien, en fait, c'est déjà le cas !

Plus tard rien ne t'empêche de changer le groupe propriétaire de ce dossier, ou d'ajouter des membres à ce groupe, de changer les droits du groupe ou d'ajouter ou retirer le bit s… les possibilités sont larges !
Ça peut même être un groupe dont ne fait pas partie l'utilisateur proprio : tant que u a les droits rwx il fait ce qu'il veut, le groupe peut n'être qu'en r-x, les utilisateurs membres de ce groupe n'auront qu'un accès lecture…

Dernière modification par Coeur Noir (Le 08/12/2018, à 18:41)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#14 Le 08/12/2018, à 18:32

Coeur Noir

Re : héritage de permissions

Enlève cette modification que tu as faite dans login.defs

Pose-toi. Lis. Relis. Réponds aux questions… quelle est ta version d'Ubuntu ? Son environnement ? Voir remarque 2. du #9

Tu es en train de te compliquer la vie pour rien : ce que tu cherches à faire est fort probablement la situation par défaut sous Ubuntu.

Ou alors explique-nous en quoi / pourquoi la situation par défaut te gêne ??? Sans contexte, comment donner des conseils pertinents ?

Et tout ça AVANT d'aller faire n'importe quoi dans des fichiers de config' système :
par ex. dans login.defs le UMASK se trouve à la ligne 151, chez moi en tout cas sous 16.04 et 14.04.

Dernière modification par Coeur Noir (Le 08/12/2018, à 18:42)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#15 Le 08/12/2018, à 18:48

Coeur Noir

Re : héritage de permissions

stylik a écrit :

Tu préconises de placer le dossier racine en 700

Par dossier racine, j'entends le dossier pour lequel tu aurais besoin d'un bit sgid. Dossier dans lequel tu voudrais que les droits de l'utilisateur soient ceux du groupe propriétaire du dossier racine.
C'est toi qui décides de quel dossier il s'agit. Pas moi.
Et cela sous entend que ce serait pour accorder des droits que l'utilisateur propriétaire n'a pas par défaut… sinon ça n'a aucun intérêt !

En l'occurrence si tu places un bit sgid sur un dossier en 700, l'utilisateur va se retrouver avec les droits du groupe, c'est à dire 700 → 0 → aucun !
Je ne t'ai certainement pas préconisé ça…

Dernière modification par Coeur Noir (Le 08/12/2018, à 19:06)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#16 Le 08/12/2018, à 20:36

bruno

Re : héritage de permissions

stylik a écrit :

L'umask de $ est passé de 0002 à 0007.
Je m'attendais à 0077.

J'ai créé un fichier :

$ touch masque

$ ll !$
ll masque
-rw-rw---- 1 stylik stylik 0 déc.   8 16:50 masque
				

Cela vous paraît-il normal ?

C'est tout a fait normal et c'est expliqué au sein même du fichier /etc/login.defs

/etc/login.defs a écrit :

# If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value
# for private user groups, i. e. the uid is the same as gid, and username is
# the same as the primary group name: for these, the user permissions will be
# used as group permissions, e. g. 022 will become 002.
#

@Cœur Noir : stylik utilise une version obsolète depuis 18 mois d'Ubuntu, voir sa signature. (Et non je ne sui pas kiné, mais j'aurais vraiment besoin de quelques séances wink)

Hors ligne

#17 Le 08/12/2018, à 22:20

Coeur Noir

Re : héritage de permissions

Je ne me fie pas trop aux signatures, on oublie souvent de les mettre à jour ;-) Et puis la 12.04 est encore maintenue, en support commercial, il me semble.


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#18 Le 09/12/2018, à 08:24

bruno

Re : héritage de permissions

C'est bien une 12.04, voir ici : ./viewtopic.php?pid=22018102#p22018102

Dernière modification par bruno (Le 09/12/2018, à 08:24)

Hors ligne

#19 Le 09/12/2018, à 15:56

stylik

Re : héritage de permissions

La configuration par défaut d'Ubuntu ne me dérangeait pas. Je me suis attelé à changer les permissions pour solutionner un problème de sauvegarde avec rsync : les permissions ne passaient pas d'un support à l'autre. Sur sdb2 les modes étaient vraiment hétérogènes, et root était propriétaire de pas mal de fichiers. J'ai considéré qu'aligner les permissions et les propriétaires pouvait aider à résoudre le problème tout en améliorant la sécurité. En fait c'est le système de fichier d'arrivée, un Toshiba USB formaté par défaut en HPFS/NTFS/ex-FAT qui bloquait le transfert à cause des options allow_other et default_permissions de la surcouche FUSE (syf virtuel par défaut). Les permissions d'origine, étaient toutes alignées en 600 à l'arrivée. D'où mon intérêt pour les masques.

Sur mon fichier /etc/login.defs le Umask est aussi à la ligne 151. Par mégarde j'ai changé la ligne 131 (celle de l'exemple) en supprimant le commentaire. Le masque prend effet quand même. J'ai corrigé pour la forme.

Concernant le choix du masque. J'ai considéré qu' « UMASK 027, or even 077, could be considered better for privacy » allait dans mon sens concernant l'alignement des permissions. Sauf qu'il s'agit d'un contexte multi-utilisateurs comme l'indique « used by useradd et newusers ». Ce qui n'est pas le cas chez moi (mais j'anticipe peut-être sans le savoir).

# UMASK is the default umask value for pam_umask and is used by useradd and newusers to set the mode of the new home directories. 
# 022 is the "historical" value in Debian for UMASK 027, or even 077, could be considered better for privacy There is no One True Answer here : each sysadmin must make up his/her # mind. 
# 
# If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value for private user groups, i. e. the uid is the same as gid, and username is the same as the primary group name: for these, the user permissions will be used as group permissions, e. g. 022 will become 002. 
# 
# Prefix these values with "0" to get octal, "0x" to get hexadecimal. 
# 
ERASECHAR	0177 
KILLCHAR	025 
UMASK		077
#UMASK		022		181208 - old	 

Stylik est le seul utilisateur sur cet ordinateur. Il crée des fichiers dont le groupe primaire porte son nom. Son groupe " privé " acquiert d'office les mêmes droits comme l'a fait remarqué Bruno.
En fait je ne crois pas être en mesure de tester ce masque 077, ni même d'expliquer dans quelle configuration il est utile. Peut-être pourriez-vous développer un exemple si c'est possible (en vous remerciant de votre attention).

Ma version d'Ubuntu est :

lsb_release -a 
No LSB modules are available. 
Distributor ID:	Ubuntu 
Description:	Ubuntu 12.04.5 LTS 

uname -a 
Linux hellgraublau 3.2.0-126-generic 

MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne

#20 Le 09/12/2018, à 18:13

Coeur Noir

Re : héritage de permissions

Sur sdb2 les modes étaient vraiment hétérogènes, et root était propriétaire de pas mal de fichiers. J'ai considéré qu'aligner les permissions et les propriétaires pouvait aider à résoudre le problème tout en améliorant la sécurité. En fait c'est le système de fichier d'arrivée, un Toshiba USB formaté par défaut en HPFS/NTFS/ex-FAT
→ on en revient à un problème de systèmes de fichiers ( ntfs qui ne gèrent pas les droits unix ) et d'options sur le montage de ce système de fichiers ( par défaut sous linux, sans option, un point de montage de volume ntfs sera attribué à root ).
→ comment est « monté » ce sdb2 ?


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#21 Le 09/12/2018, à 21:35

stylik

Re : héritage de permissions

Le disque où sont les données à sauvegarder est le sdb2 évoqué ici
Les options de montage dans la fstab sont :

UUID=66d917c0-f184-43f5-aa51-1912ab91b12a	/media/sdb2	reiserfs  rw,nouser,nodev,nosuid,noauto,noexec	0	0 

Ces options n'apparaissent pas dans la commande mount. Selon Maxire il est difficile de savoir pourquoi compte tenu de l'obsolescence du système d'exploitation. Je pense que les options sont effectives, mais si elles ne le sont pas ce n'est pas grave … Je viens de les ajouter car j'améliore ma configuration au fur et à mesure, en autodidacte.


Le disque d'arrivée (DA) est un Toshiba USB formaté par défaut en HPFS/NTFS/ex-FAT. Il est doté d'un système de fichier virtuel FUSE avec des options allow_other et default_permissions qui m'ont posé problème car elles empêchent de conserver les permissions d'origines.

#mount 
(…) 
/dev/sdc1 on /media/DA type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096) 

Je ne connaissais pas ce masque " matériel ".
C'est Bruno qui m'a apporté ici les information sur ces options.
La commande chmod est inefficace sur ce disque. Les permissions restent en 700/600. Je me suis interrogé sur le paramétrage de " default_permissions " pour les changer.

Je me suis interrogé aussi à propos du « masque utilisateur du récepteur » évoqué par Delafond dans le man rsync concernant l'option -p.

Le transfert des SEULES permissions avec rsync est assez compliqué à obtenir, pour restaurer des permissions par exemple.
Est-ce une utilisation 'exclusive' possible ?


MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne

#22 Le 09/12/2018, à 22:28

stylik

Re : héritage de permissions

Puisque qu'on évoque les masques " matériels ", ceux qui sont inscrits (par défaut) dans les options de montage du système de fichier,  je vous transmets un autre exemple de masque, sur une une clé USB cette fois (dmask =0077).

/dev/sdc1 on /media/USB16 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks) 

Les permissions sont immuables avec chmod.
Est-ce justifié pour une clé USB ?


MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne

#23 Le 09/12/2018, à 22:45

Coeur Noir

Re : héritage de permissions

T'es pas facile à suivre stylik ;-) je n'arrive toujours pas à comprendre ce que tu veux faire / le résultat que tu cherches à obtenir / ou ce qui coince dans ton usage actuel ?

/media/sdb2 → on a là du reiserfs qui gère les droits unix → donc assure-toi que le point de montage /media/sdb2 accorde à l'utilisateur propriétaire les droits rwX. Et par conséquent que tout ce qui se trouve dans ce disque appartient bien à cet utilisateur.

  • Retours de

    ls -la /media
    ls -la /media/sdb2
  • Je m'interroge sur l'intérêt du reiserfs ?

/dev/sdc1 → si c'est un système de fichiers non unix ( ntfs, fat, etc… ) → par défaut Linux lui attribuera root comme propriétaires ( utilisateur et groupe ) → donc pour lui c'est au niveau des options de son montage qu'il faut dire au système à qui il doit attribuer cette partition.

  • Celui-là comment il est monté, avec quelles options ? Il est dans ton fstab ?

  • Sur celui-là, puisque système de fichiers non unix, il n'y a pas d'idées de droits / permissions sur les fichiers contenus. C'est juste une émulation au niveau du montage.

  • Là aussi je m'interroge : est-ce que sdc1 est utilisé par un système windows ? Car formaté par défaut en HPFS/NTFS/ex-FAT bah nan les 3 à la fois c'est pas possible, c'est l'un de ceux-là mais lequel ?

Peut-être qu'on y verrait plus clair avec

cat /etc/fstab
df -Th
sudo blkid
ls -la /media/DA

et cela avec le DD externe connecté ( si j'ai bien compris sdc1 ici est le disque Toshiba ? ).

Bon et puis comme te l'ont déjà dit les camarades, 12.04 est morte en support « gratuit » depuis belle lurette maintenant - à moins que tu sois en support payant étendu ? Ou fais-tu tout cela pour préparer des sauvegardes et une migration, en tout cas songes-y sérieusement… mais simplement ( la 16.04 est encore très bien, maintenue jusqu'en 2021 ).

Dernière modification par Coeur Noir (Le 09/12/2018, à 23:04)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#24 Le 09/12/2018, à 23:01

Coeur Noir

Re : héritage de permissions

stylik a écrit :
/dev/sdc1 on /media/USB16 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks) 

Les permissions sont immuables avec chmod.
Est-ce justifié pour une clé USB ?

…ok je vais finir par croire que :

  • tu ne lis pas les réponses qu'on te fait,

  • ni les liens ou documentations proposées

→ Ta clé usb est en vfat - donc pas unix donc linux lui applique une « émulation » de droits,
→ c'est une clé usb, un média amovible, donc traitée automatiquement pour que l'utilisateur puisse lire-écrire dessus, d'où ce masque et les attributions uid et gid.
→ permissions immuables, bah oui, c'est vfat, il ne sait pas ce que c'est les permissions. Tout juste peux-tu jouer sur le point de montage mais peu d'intérêt… sinon de te bloquer l'accès.

Et scoop, ce sera pareil avec un disque dur externe en ntfs, mais c'est pas grave : ce qui importe c'est que ton utilisateur puisse écrire-lire dessus. Ouf, c'est la situation par défaut.

Tu peux arrêter de t'éparpiller, et recentrer sur UN thème, UNE idée, ou UN souhait steuplééé ?

Dernière modification par Coeur Noir (Le 09/12/2018, à 23:11)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#25 Le 10/12/2018, à 14:22

stylik

Re : héritage de permissions

Je m'éparpille , je m'éparpille … désolé, ce n'est pas toujours simple de circonscrire un problème à « UN thème, UNE idée, ou UN souhait ». Ce n'est pas faute d'essayer de simplifier mes questions.
Malheureusement, si tes contributions sont instructives et que d'une certaine façon je t'en suis redevable, elles ne répondent pas pour autant à toutes mes questions, d'où mon insistance. Ce sont des questions erratiques et peut-être un peu lourdes j'en conviens.
Mais des questionnements "sans intérêts" peuvent consolider des bases théoriques, surtout pour un autodidacte. La documentation sur Internet est foisonnante mais souvent redondante et basique. Il est difficile de trouver des réponses pointues à des questions précises. C'est tout l'intérêt d'un forum de pouvoir répondre à ces questions concrètes. Or tu ne vas pas assez loin dans tes explications techniques.

Quand tu m'apportes une réponse générique du type « linux lui applique une « émulation » de droits », je te répondrais que je l'avais bien compris depuis que Bruno m'a briffé sur le système de fichier FUSE. Précisément « Je me suis interrogé sur le paramétrage de " default_permissions ". Si linux gère automatiquement les permissions à la place de vfat, c'est que l'émulation est paramétrable …  Est-ce au niveau de udev que ça se passe … peut-être.

Quelle est l'utilité d'un masque 077 exemple à l'appui dans un contexte multiutilisateurs.
Je n'évoque pas le « masque utilisateur du récepteur » qui reste une énigme pour moi.
Ni la gestion des seules permissions avec rsync.

Sur ce, le fil tourne en boucle et je conçois que pour toi ce soit fastidieux de "rabacher les bases" donc je le clos.
Le sujet des permissions est vaste et il est facile de s'éparpiller.

Sincèrement merci de votre attention, à toi, Bruno et Maxire.
Tant bien que mal, 10 à 20 % d'avancement sur mes projets c'est mieux que rien.

Bonne continuation à vous.


MSI K9N SLI-2F, MSI R7-260X, Athlon X2, Ubuntu 12.04

Hors ligne