Utilisateurs en lecture seule... qui peuvent supprimer des fichiers !

PierU · le 13 mai 2019

Bonjour,

j'ai un souci sur les permissions : j'avais créé pour des amis des comptes utilisateurs qui ont accès en lecture seule à un unique dossier partagé, en se connectant par FileStation. Or je viens de me rendre compte que ces comptes peuvent supprimer des fichiers ! Et je ne comprends pas pourquoi...

Voilà les permissions de groupes de ce dossier : http://prntscr.com/no4803 ... Les utilisateurs concernés sont dans le groupe "MeMs", qui est en lecture seule. Le seul groupe qui a les droits d'écriture est "Administrators", qui ne contient pas ces utilisateurs.

Si on regarde les permissions d'utilisateurs du dossier : http://prntscr.com/no4c0r ... Les deux utilisateurs concernés ont des flèches rouges, et on voit qu'ils n'ont pas de permissions particulières en écriture qui contrediraient celles du groupe.

Je ne comprends pas, où est la faille ?

Modifié le 13 mai 2019 par PierU

DaffY · le 14 mai 2019

Bonjour,

Probables incohérences users groupe etc...
Les simples impressions écrans ne suffisent pas.
Dispo par mp pour faire un point direct si souhaité

PierU · le 14 mai 2019

il y a 49 minutes, daffy a dit :

Dispo par mp pour faire un point direct si souhaité

En MP j'ai l'erreur " daffy ne peut pas recevoir de messages. "

DaffY · le 14 mai 2019

MP fait.

unPixel · le 14 mai 2019

Bonjour,

Faudrait voir directement en ssh les droits attribués et éventuellement changer ça.

Daffy est sur le coup 🙂

PierU · le 14 mai 2019

OK... Pour l'accès SSH ça attendra ce soir, je n'ai pas accès pendant la journée.

Information complémentaire : les fichiers qui sont écrits dans ce dossier le sont par l'intermédiaire d'un partage NFS vers mon ordi, avec du côté Syno l'option "mappage de tous les utilisateurs sur admin"

DaffY · le 14 mai 2019

Ok,

vu par MP la problématique n'est pas urgente et l'écriture gérée par Linux présuppose j'imagine des connaissances et compétences permettant à @PierU, une capacité à investiguer sur les dossiers via accès Telnet/SSH au NAS.

A suivre...

unPixel · le 14 mai 2019

Tiens nous au courant 🙂

PierU · le 14 mai 2019

De passage de en coup de vent chez moi à midi, les fichiers en question tels que vus depuis le NAS lui-même apparaissent ainsi :

-rwxrwxrwx  1 admin users  6420768 Feb 15  2015 xxxxxxxxxxxxx.pdf

"admin" à cause du mappage NFS, pour le reste rien qui me semble anormal. Enfin, presque... Si je compare avec d'autres fichiers sur des partages accédés seulement en SMB je vois ça (j'ai remplacé le nom de l'utilisateur) :

-rwxrwxrwx+ 1 utilisateur1 users    516 Mar 23 20:51 xxxxxxxxxxxxxxx.plist

Il y a le "+" derrière les permissions.

Il y a 2 heures, daffy a dit :

vu par MP la problématique n'est pas urgente et l'écriture gérée par Linux présuppose j'imagine des connaissances et compétences permettant à @PierU, une capacité à investiguer sur les dossiers via accès Telnet/SSH au NAS.

A investiguer peut-être, mais pas forcément à comprendre ce qui se passe ! Je suis plus utilisateur qu'administrateur... (en l'occurrence le montage est sur un macOS, mais j'utilise aussi Linux).

unPixel · le 14 mai 2019

Je suis moi même utilisateur que sysadmin 🙄

Est-ce que le soucis viendrait pas du groupe "users" justement ?

Citation

-rwxrwxrwx 1 admin users 6420768 Feb 15 2015 xxxxxxxxxxxxx.pdf

PierU · le 14 mai 2019

Il y a 1 heure, Zeus a dit :

Est-ce que le soucis viendrait pas du groupe "users" justement ?

Si ce groupe "users" listé dans le shell correspond bien au groupe "users" dans l'interface DSM, il n'est censé avoir aucun accès à ce partage (même pas en lecture, voir premier post)

DaffY · le 14 mai 2019

Re,

La problématique est sans doute qu'un utilisateur dispose de droits supérieurs aux autres utilisateurs peut être ?

a vérifier :

si on a 4 utilisateurs sur mac
chaque utilisateur appartienne à un groupe
le groupe dispose de droits précis sur le dossier en question
si , on se connecte VIA cet utilisateur sur le mac et qu'on accède alors au partage NFS on dispose des mêmes droits.

ce qui peut en revanche se produire (car l'interface est la même pour le 'client') c'est qu'à partir d'une même machine un utilisateur disposant de droits supérieurs accède aussi à ce même dossier... du coup cela peut générer des différences d'accès pour les autres.

L'appropriation des droits de cet utilisateur et les éventuelles restriction de son groupe, n'autorisant pas l'accès aux autres.... (ie : la 1ere connexion au montage est signée et hop on ne se sait plus avec quel utilisateur on écrit sur le dossier en question.)

Par ailleurs c'est pour une utilisation avec FCPX le montage NFS sur mac ? un montage afp ou smb ne convient pas ? (c'est une question un peu HS)

PierU · le 14 mai 2019

Il y a 3 heures, daffy a dit :

La problématique est sans doute qu'un utilisateur dispose de droits supérieurs aux autres utilisateurs peut être ?

a vérifier :

si on a 4 utilisateurs sur mac

chaque utilisateur appartienne à un groupe

le groupe dispose de droits précis sur le dossier en question

si , on se connecte VIA cet utilisateur sur le mac et qu'on accède alors au partage NFS on dispose des mêmes droits.

ce qui peut en revanche se produire (car l'interface est la même pour le 'client') c'est qu'à partir d'une même machine un utilisateur disposant de droits supérieurs accède aussi à ce même dossier... du coup cela peut générer des différences d'accès pour les autres.

L'appropriation des droits de cet utilisateur et les éventuelles restriction de son groupe, n'autorisant pas l'accès aux autres.... (ie : la 1ere connexion au montage est signée et hop on ne se sait plus avec quel utilisateur on écrit sur le dossier en question.)

Euh... Je n'ai pas compris grand-chose 😐. Je (re)précise néanmoins que l'export NFS se fait avec l'option "mappage de tous les utilisateurs sur admin" sur le Syno : du coup les permissions des utilisateurs déclarés sur le Mac n'ont (en principe) aucune importance/influence...

Il y a 3 heures, daffy a dit :

Par ailleurs c'est pour une utilisation avec FCPX le montage NFS sur mac ? un montage afp ou smb ne convient pas ? (c'est une question un peu HS)

Une des raisons c'est que le débit atteint avec le partage NFS est de 75Mo/s (écriture) / 90Mo/s (lecture), contre 50Mo/s avec SMB ou AFP.

Une autre raison est que le montage NFS n'est pas détecté comme un disque réseau mais comme des données locales par un utilitaire que j'utilise, et ça m'arrange.

DaffY · le 14 mai 2019

Bonsoir

a / smb et afp bien paramètrés disposent des mêmes temps de réponse que nfs. (Encore un très léger avantage sur Mac pour afp y compris sous Mojave) Maintenant tu es évidemment libre et semble t’il contraint par un utilitaire à utiliser le protocole nfs. No problemo

2/ si tous les utilisateurs du partage se connectent en tant qu’admin du nas je ne vois plus ou est le pb (enfin si mais c’est un autre ... que d’utiliser ce compte de manière partagé)

Bref, dans l’ordre peut on avoir les précisions suivantes afin de bien cerner la problématique

1/ Un dossier du nas est partagé

2/ Un groupe et/ou des utilisateurs sont présents (côté NAS) pour accéder soit en lecture seule soit en lecture et écriture sur ce dossier

3/ C’est cet utilisateur qui via une machine se connecte en utilisant le protocole nfs ET en s’identifiant avec user et mot de passe définis sur le NAS (indépendamment du fait que chaque utilisateur est admin de sa propre machine)

4/ il arrive que certains fichiers déposés modifiés par 1 utilisateur ne soient plus accessibles pour les autres nécessitant une intervention de l’admin du nas sous FileStation (j’imagine) pour ‘remettre l’ordre souhaité ‘ en terme de propriété

Sommes nous d’accord ?

Envoyé de mon iPhone en utilisant Tapatalk

PierU · le 15 mai 2019

Il y a 11 heures, daffy a dit :

a / smb et afp bien paramètrés disposent des mêmes temps de réponse que nfs. (Encore un très léger avantage sur Mac pour afp y compris sous Mojave)

Disons que out of the box (sans aucun effort d'optimisation) j'avais les perfs suivantes en lecture : SMB=25Mo/s, AFP=50Mo/s, NFS=90Mo/s. En désactivant la "signature des paquets" côté Mac (je suppose que concrètement ça veut dire le chiffrement) j'atteins 50Mo/s en SMB aussi. Je n'ai pas cherché vraiment plus loin.

Il y a 11 heures, daffy a dit :

2/ si tous les utilisateurs du partage se connectent en tant qu’admin du nas je ne vois plus ou est le pb (enfin si mais c’est un autre ... que d’utiliser ce compte de manière partagé)

Oui je sais que ce n'est pas franchement satisfaisant ! Si encore j'étais le seul utilisateur du Mac ça irait, mais là c'est moyen on est d'accord.

Il y a 11 heures, daffy a dit :

Bref, dans l’ordre peut on avoir les précisions suivantes afin de bien cerner la problématique

1/ Un dossier du nas est partagé
2/ Un groupe et/ou des utilisateurs sont présents (côté NAS) pour accéder soit en lecture seule soit en lecture et écriture sur ce dossier
3/ C’est cet utilisateur qui via une machine se connecte en utilisant le protocole nfs ET en s’identifiant avec user et mot de passe définis sur le NAS (indépendamment du fait que chaque utilisateur est admin de sa propre machine)
4/ il arrive que certains fichiers déposés modifiés par 1 utilisateur ne soient plus accessibles pour les autres nécessitant une intervention de l’admin du nas sous FileStation (j’imagine) pour ‘remettre l’ordre souhaité ‘ en terme de propriété

Sommes nous d’accord ?

1) oui

2) oui. En lecture/écriture le groupe admin (et personne d'autre), et en lecture seule (en principe) entre autre le groupe "MeMs" qui me pose problème actuellement.

3) Non. En NFS il n'y a concrètement que moi qui me connecte à ce partage, depuis le Mac, pour y déposer des fichiers. Les utilisateurs du groupe MeMs se connectent en pratique par File Station (avec leurs ident/mdp).

4) Non. Le problème est que les utilisateurs du groupe MeMs peuvent en pratique faire tout ce qu'ils veulent (supprimer des fichiers, en créer, etc...), alors que dans l'interface DSM ils n'ont en principe que les droits en lecture. Le problème est le même s'ils se connectent par SMB en fait.

DaffY · le 15 mai 2019

il y a 11 minutes, PierU a dit :

Le problème est que les utilisateurs du groupe MeMs peuvent en pratique faire tout ce qu'ils veulent (supprimer des fichiers, en créer, etc...), alors que dans l'interface DSM ils n'ont en principe que les droits en lecture. Le problème est le même s'ils se connectent par SMB en fait.

Bonjour,

pardon, mais, si

il y a 12 minutes, PierU a dit :

En lecture/écriture le groupe admin (et personne d'autre), et en lecture seule (en principe) entre autre le groupe "MeMs" qui me pose problème actuellement.

un utilisateur du groupe désigné, limité à une lecture simple sur le dossier, ne peut écrire sur le dossier.

Sauf si, ce même utilisateur dispose de droits d'écriture par ailleurs... Donc :

Bien investiguer les groupes avec leur droits
- On est bien d'accord c'est un dossier partagé (1er niveau du NAS) et personnel (pas d'un dossier music, video ou home/homes... qui sont des dossiers "réservés par DSM" dirons nous pour l'instant.)
- Vérifier que les utilisateurs soient dans ce groupe et seulement ce groupe (exception faite de users -- tous les utilisateurs sont obligatoirement dans users-- un utilisateur ne doit pas être dans d'autres groupes)
- Vérifier que pour chaque utilisateur, ce sont les droits hérités du groupe qui apparaissent et non un surenchérissement (ie rien de coché en lecture écriture sur le dossier concerné puisque déjà indiqué dans le groupe ..)

Merci pour le retour

unPixel · le 15 mai 2019

Ne faudrait-il pas attribuer le dit groupe à autre chose que "users" ?

PierU · le 15 mai 2019

il y a une heure, daffy a dit :

un utilisateur du groupe désigné, limité à une lecture simple sur le dossier, ne peut écrire sur le dossier.

Ben oui... normalement. Et le problème est que justement ils peuvent.

il y a une heure, daffy a dit :

Bien investiguer les groupes avec leur droits

On est bien d'accord c'est un dossier partagé (1er niveau du NAS) et personnel (pas d'un dossier music, video ou home/homes... qui sont des dossiers "réservés par DSM" dirons nous pour l'instant.)

Oui, c'est un dossier partagé que j'ai créé : https://i.imgur.com/rZRdPHr.png
Ses permissions de groupe (seul le groupe admins a les permissions d'écriture) : https://i.imgur.com/zOH16RO.pn
Ses permissions d'utilisateurs (avec un des utilisateurs concernés entouré en rouge) : https://i.imgur.com/f0N7Ix6.png

Il y a 1 heure, daffy a dit :

Vérifier que les utilisateurs soient dans ce groupe et seulement ce groupe (exception faite de users -- tous les utilisateurs sont obligatoirement dans users-- un utilisateur ne doit pas être dans d'autres groupes)

C'est bien le cas : https://i.imgur.com/jvWLTzN.png

Il y a 1 heure, daffy a dit :

Vérifier que pour chaque utilisateur, ce sont les droits hérités du groupe qui apparaissent et non un surenchérissement (ie rien de coché en lecture écriture sur le dossier concerné puisque déjà indiqué dans le groupe ..)

https://i.imgur.com/Hxl0sxK.png

il y a une heure, Zeus a dit :

Ne faudrait-il pas attribuer le dit groupe à autre chose que "users" ?

Tu veux dire retirer ces utilisateurs du groupe "users" ? Mais ce groupe n'a aucune permission définie sur le dossier partagé en question, donc ça ne devrait rien changer (non ?)

unPixel · le 15 mai 2019

Non je parlais du groupe "users" sur le dossier.

Mais après, ils auront peut-être le soucis de lecture. Encore une fois, je suis pas l'expert ici des droits Unix.

DaffY · le 15 mai 2019

Bonjour,

non tous les utilisateurs sont par défaut sur le groupe users, et on ne gère rien sur ce groupe.

En revanche attendu qu'il y'a un partage NFS il est probable que les users soient sur la même ip. Si ces derniers n’accèdent pas via NFS il faut sans doute specifier l'ip concernée pour le montage et le mappage de l'unité NFS que pour la machine du user admin qui utilise le montage NFS.

par ailleurs si les options sont mises par défaut, possible que la réorganisation faite sur le dossier (donc droits ACL) peuvent perturber (cf aide service de fichier) l'ensemble.

A voir :

Le dossier possède nativement une gestion ACL où est il possible de le convertir ? (cf propriété du dossier : panneau de configuration dossier partagé, menu action.)

Si l'option est proposée (non grisée ne pas l'activer pour le moment) dans ce cas, sous File Station rendre explicite les droits pour que ce dernier se réapproprie les droits selon les groupes.

Vérifier en se connectant VIA FileStation en connexion http/https donc, avec un user du groupe en question, l'utilisateur ne doit pas pouvoir y écrire.

PierU · le 16 mai 2019

Je progresse... au moins dans la correction problème à défaut de comprendre comment il est arrivé.

Dans les propriétés du dossier partagé (celles obtenues dans FileStation, pas dans le panneau de config), les permissions du dossier racine sont conformes à ce que j'attends : https://i.imgur.com/1dxHwj5.png (et pour répondre à Daffy, dans les propriétés du dossier partagé dans le panneau de config, l'action "Covertir en Windows ACL" est grisée pour tous les dossiers).

Par contre les permissions des sous-dossiers et des fichiers pas du tout ! Exemple sur un des sous-dossiers : https://i.imgur.com/yvRdpaa.png ... il y a un "everyone" qui apparait, avec des permissions en écriture ! J'ai l'impression que ce sont les permissions unix qui ont refait surface à la place des permissions DSM.

Du coup je suis remonté dans les propriétés de la racine, onglet permissions, j'ai coché "Appliquer à ce dossier, ces sous-dossiers, et ces fichiers" et fait OK... Et là tout semble rentrer dans l'ordre sur les sous-dossiers : https://i.imgur.com/QfJLuUF.png... et les utilisateurs du groupe MeMs ne peuvent en effet plus supprimer de fichier, OUF !

Il y a 20 heures, daffy a dit :

sous File Station rendre explicite les droits pour que ce dernier se réapproprie les droits selon les groupes.

C'est ce que tu as écrit là qui m'a mis la puce à l'oreille sur les droits explicites ou hérités par les sous-dossiers (je me souvenais avoir déjà vu ça dans FileStation).

Bon, ça n'explique pas pourquoi les droits n'étaient plus les bons, mais c'est au moins rentré dans l'ordre pour l'instant.

DaffY · le 16 mai 2019

Bonjour,
Tant mieux si ça avance. Possible corruption par une connexion nfs réalisée avec un utilisateur du groupe en question.cela pourrait expliquer la corruption.
A suivre

Envoyé de mon iPad en utilisant Tapatalk

PierU · le 17 mai 2019

Oui il faut que je regarde à tête reposée ce qui se passe côté NFS...

PierU · le 18 mai 2019

Bien, j'ai regardé :

Sur le montage NFS du dossier partagé, depuis le Mac :

dans le Finder je crée un nouveau sous-dossier, et je regarde ensuite ses permissions dans File Station : ce sont les "bonnes", telles que définies pour le dossier partagé dans DSM
toujours dans le Finder je copie des dossiers/fichiers du Mac vers le dossier partagé : dans ce cas, leurs permissions sont les permissions unix que ces fichiers avaient sur le Mac, sans aucun lien avec les permissions du dossier partagé !

Déjà le comportement n'est pas vraiment cohérent entre les deux, mais du coup je comprends pourquoi n'importe qui pouvait supprimer les fichiers sur le dossier partagé dont je parlais au début : ils ont été recopié à l'origine depuis un disque externe en exFAT, qui ne gère pas de permissions. Dans ce cas macOS attribue implicitement les permissions en lecture/écriture pour tout le monde, donc les fichiers ont été recopiés avec ces permissions là sur le NAS.

Conclusion : je vais me restreindre à l'utilisation de NFS en lecture seule dorénavant !

EDIT : je rappelle que j'utilise les paramètres NFS suivants côté Syno : "Authentification Sys" et "Mappage de tous les utilisateurs sur admin"; ça fonctionne peut-être différemment avec d'autres paramètres.

DaffY · le 18 mai 2019

Mouais... je confirme qu’avec une connexion smb ou afp on a pas ce genre de souci...

Le montage nfs étant assuré en tant qu’admin c’est pour moi normal. Les droits unix sont récupérés sur la destination puisqu user = admin

Envoyé de mon iPad en utilisant Tapatalk

Connexion

Utilisateurs en lecture seule... qui peuvent supprimer des fichiers !

Messages recommandés

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Rejoindre la conversation

Qui est en ligne 2 membres, 0 anonyme, 772 invités (Afficher la liste complète)

Contributeurs populaires

Information importante