Share toegang op basis van User en Group settings

[Plerry]

Misschien een "sticky" topic?

Er blijkt veelvuldig onduidelijkheid of misverstand te bestaan over de toegangsrechten voor shares,
vooral wanneer er sprake is van een combinatie van Group- en User-level settings.
Zoals Synology zelf in de DSM help-file al aangeeft, wordt bij conflicten de volgende prioriteit
gehanteerd:
GeenToegang/NoAccess > LezenSchrijven/ReadWrite > Lezen/Read
Wat minder helder naar voren komt is de relatie met wanneer niets is aangevinkt.
Niets aanvinken (ik noem dat hier "Blank") kan het best beschouwd worden als een NoAccess
met de laagste prioriteit.
De totale prioriteit komt daarmee effectief uit op: NoAccess > ReadWrite > Read > Blank.

Wanneer nu bevoegdheden worden ingesteld op zowel User- als Group-level leidt dat
voor die User (wanneer lid van die bewuste Group) tot het volgend schema:



Een aantal belangrijke conclusies:

• Wanneer voor een share noch op User- noch op Group-level toegangsbevoegdheden zijn aangevinkt heeft niemand toegang. Het is dan ook zelden nodig om NoAccess aan te vinken.
• Wanneer voor een Group voor een bepaalde share NoAccess wordt aangevinkt heeft geen enkele User die lid is van die Group toegang tot die share, ook al is voor zo'n User voor die share ReadWrite of Read aangevinkt.
• Omdat alle users altijd lid zijn van de standaard Group "users" heeft bij het aanvinken van NoAccess voor de Group "users" voor een share, niemand meer toegang tot die share.
• Is een User lid van meerdere groepen dan geldt per share de setting met de hooste prioriteit van de User-settings samen met de settings van alle groepen waarvan die User lid is.

Hopelijk schept dit wat licht in de duisternis.

Plerry

[r00n]

Thanks... altijd handig om het even in een kort verhaaltje terug te lezen.

[Matr1x]

• Wanneer voor een Group voor een bepaalde share NoAccess wordt aangevinkt heeft geen enkele User die lid is van die Group toegang tot die share, ook al is voor zo'n User voor die share ReadWrite of Read aangevinkt.

Klopt dit wel? Volgens mij gaan user settings voor op group settings. Want zo kun je juist de groep moderators geen toegang geven, behalve Matr1x. Of omgekeerd, de groep moderators heeft volledige toegang, behalve Plerry.

DSM geeft een melding als je een groep rechten geeft op een share en ook nog eens een gebruiker die ook in die groep zit. Maar volgens mij is dit een waarschuwing dat er tegenstrijdige rechten zijn gegeven.

Ik zal eens wat testjes doen...

[r00n]

Zit er ook over na te denken. Ik heb niet veel gebruikers, dus ik heb netjes aangegeven dat de groep users alles mag. Per gebruiker vink ik dan alles uit wat niet mag. Uiteindelijk kunnen ze wat ik op gebruikers niveau heb ingeschakeld.

[Matr1x]

Zit er ook over na te denken. Ik heb niet veel gebruikers, dus ik heb netjes aangegeven dat de groep users alles mag. Per gebruiker vink ik dan alles uit wat niet mag. Uiteindelijk kunnen ze wat ik op gebruikers niveau heb ingeschakeld.

Dan is mijn aanname toch juist: rechten ingestel voor gebruiker gaat voor op rechten ingesteld voor de groep (waar gebruiker in zit).

[wizjos]

Zit er ook over na te denken. Ik heb niet veel gebruikers, dus ik heb netjes aangegeven dat de groep users alles mag. Per gebruiker vink ik dan alles uit wat niet mag. Uiteindelijk kunnen ze wat ik op gebruikers niveau heb ingeschakeld.

Dan is mijn aanname toch juist: rechten ingestel voor gebruiker gaat voor op rechten ingesteld voor de groep (waar gebruiker in zit).

Klinkt logisch . Zo kan je een user  'uit de groep trekken' en meer rechten geven dan standaard.
@Plerry: Plakker geplaatst

[Plerry]

...Klopt dit wel? Volgens mij gaan user settings voor op group settings. ...
Dan is mijn aanname toch juist: rechten ingestel voor gebruiker gaat voor op rechten ingesteld voor de groep (waar gebruiker in zit).

Klinkt logisch . Zo kan je een user 'uit de groep trekken' en meer rechten geven dan standaard.

Het mag dan logisch klinken, maar het is niet juist ...

De help-file (van DSM V4.0) shrijft het ook heel nadrukkelijk:
"Note: When you encounter privilege conflicts, the privilege priority is as follow:
No access > Read/Write > Read only."
Ik heb daar slechts het (laagste) niveau Blank aan toegevoegd.
Mijn ervaringen met DSM 2.0 waren daarmee al in lijn, en voor de zekerheid heb ik het
(voor DSM4.0) nog even gecontroleerd. En echt: bovenstaand schema klopt.

Het is dus echt zo dat de prioriteit van de setting die bij conflicten bepaalt wat de rechten
zijn, en niet dat User-setting boven Group settings zouden gaan.

In sommige gevallen is het effect van beide hetzelfde:
(er wordt een User verondersteld die lid is van de bewuste Group):

• Is de Group-setting Blank en de User-setting Read of ReadWrite, dan heeft de (rest van de) Group geen toegang en de User Read resp. ReadWrite rechten.
• Is de Group-setting Read en de User-setting ReadWrite, dan heeft de (rest van de) Group Read rechten en de User ReadWrite rechten.

Echter:

• Is de Group-setting NoAccess en de User-setting Read of ReadWrite, dan heeft noch de (rest van de) Group noch de User toegang. (Het beruchte lockout probleem)
• Is de Group-setting ReadWrite en de User-setting Read, dan heeft zowel de (rest van de) Group als de User ReadWrite rechten.

Als je het niet gelooft: probeer het zelf maar!

Plerry

[Matr1x]

Ok, ik begrijp nu hoe het werkt en dat maakt het best lastig. De volgorde van rechten bepaalt dus welke van toepassing is, ongeacht je deze op een groep of op een gebruiker zet. Is die van de groep hoger, dan is die van toepassing. Is die van een gebruiker hoger, dan is die van toepassing.

En dit is de enige juitse volgorde: NoAccess > ReadWrite > Read > Blank (ook NoAccess).

Dan heb je dus 2 mogelijkheden:
1) alles dicht zetten en per group of gebruiker de uitzondering. Dit werkt dus dus alleen als je voor het dichtzetten geen keuze maakt en de rechten dus blanco houdt. Alleen dan werken de uitzonderingen en kun je zelfs een gebruiker die in een goep zit die je R of RW geeft uitsluiten door die gebruiker op NA te zetten.
2) alles moet open zetten met R of RW en per groep of gebruiker de uitzondering. Dit werkt door een groep NA te geven, maar daar kun je niet meer over heen door een gebuiker uit die groep weer R of RW te geven. Hier kun je dus moeilijker uitzonderingen maken.

Optie 1) is dus het beste om te doen en sowieso het minste werk.

Heel erg bedankt voor de uitleg Plerry. Ik heb zelf altijd optie 1) gebruikt en ging dat per toeval dus goed. Nu het mij duidelijk is hoe het echt werkt, kan ik elke situatie uitleggen en (nog) beter ondersteuning geven.  

[Plerry]

Deze Synology methode van prioriteit gebaseerde conflict hantering lijkt ook de enige bruikbare methode op het moment dat een User lid is van meerdere Groups waarvoor verschillende bevoegdheden kunnen zijn ingesteld voor een share.

Het verwarrende is dat het een ander systeem van User en Group(s) is dan bekend vanuit Linux. Daar geef je met "chmod" simpelweg apart de bevoegdheden van de User/Owner, de Group en de Rest (of the world).
Maar, daar is altijd slechts sprake van één Group, niet van meerdere tegelijk.

Plerry

[Plerry]

Uit PM's blijkt dat je kennelijk nooit duidelijk genoeg kan zijn.

Daarom hier een kleine aanvulling op de tabel in mijn eerste posting.
Deze aanvulling maakt wat explicieter wat er gebeurt wanneer een user,
naast de groep "users", lid is van één of meer andere groepen.
Bovendien heb ik het lage-prioriteit NoAccess vakje (rechtsonder)
wit gemaakt (in plaats van rood), om de uitwerking van de prioriteit
duidelijker te maken. Daarnaast nog de opmerking toegevoegd dat,
omdat de user- en groep-settings per share (kunnen) verschillen,
de tabel per share geldt (en dus per share kan verschillen).

Tenslotte: groep-settings zijn uitsluitend van belang  indien de user
waaronder verbinding met de NAS wordt gemaakt lid is van die groep(en).
En bedenk: elke user is altijd lid van de groep "users".
Hopelijk is het zo (nog?) duidelijker.

Plerry

[ton123]

Plerry dank voor de uitleg!
Echter het volgende lukt mij niet:
Ik wil userRO1, userRO2 en userRO3 READ ONLY toegang geven tot SHARE1. Ze moeten kunnen lezen en downloaden. Uiteindelijk remote via internet.
userRW moet de bestanden op de SHARE1 kunnen lezen, schrijven, deleten, downloaden, kortom alles.

userRO1 tm RO3 en userRW zitten in de group users
userRO1 tm RO3 zitten ook nog in de group usersROSHARE1
bij de group users heb ik de rechten nergens aangevinkt
bij de group usersROSHARE1 heb ik aangevinkt Readonly
bij userRO1 tm RO3 heb ik aangevinkt Readonly bij SHARE1
bij userRW heb ik aangevinkt Read/Write bij SHARE1
bij SHARE1 staan de rechten voor Local groups:
readonly voor group users ROSHARE1
readwrite voor group users
bij SHARE1 staan de rechten voor users:
Read/write voor userRW
Bij advanced privalidges heb ik niets aangevinkt.

Resultaat in de tabel is in het oranje Read/write bij zowel Priviliges als Preview.

Ik begrijp hier niets van .......
De userRO1 tm userRO3 kunnen vrolijk schrijven en muteren...

Dat is niet wat ik wil.

Waar zit mijn fout?
Of beter, hoe krijg ik dit wel voor elkaar?

Verder begrijp ik ook het effect niet van het modificeren van de rechten van de bestanden en de mappen en de submappen en dan vooral ook niet in de relatie met het voorgaande. Bovendien is het mogelijk een gewone vink te zetten en bij nogmaals klikken een zwarte vink. Geen idee of dit verschil maakt.

DSM4.2-3202 op DS412+

[Matr1x]

readwrite voor group users

Hier gaat het dus fout volgens mij. De groep users zit automatisch iedereen in.

[Plerry]

Matr1x legt waarschijnlijk de vinger op de zere plek.

Maar ..., je bent veel te ingewikkeld bezig.
Daardoor valt bijna niet meer te snappen wat je doet.

Het kan veeeel simpeler:
Haal alle bevoegdheden voor SHARE1 weg (niets aanvinken),
behalve:
* voor de group usersROSHARE1: ReadOnly
* voor de user userRW: ReadWrite

Eventueel mag ook userRW lid zijn van de group usersROSHARE1,
omdat de ReadWrite setting voor userRW een hogere prioriteit heeft dan
de ReadOnly setting voor usersROSHARE1.

[ton123]

Reacties van Matr1x en Plerry beiden goed.
Vooral Plerry's maning tot eenvoud maakt het voor mij ook weer te begrijpen!

Het werkt nu dus precies zoals ik wil, ook al via Internet!

[lexeman]

Beste forum leden,

Bedankt voor deze uitgebreide post en links, maar toch kom ik er niet uit.

Op dit moment heeft mijn zoon een playstation 3 en kan alle gedeelde mappen (video, music,Photo) zien, ZONDER INLOG???!!!!
Dat wil ik niet en al helemaal niet dat hij er alles mee kan doen.
Graag wil ik het volgende inregelen:
1.   hij zou moeten inloggen lijkt me
2.   hij mag alleen een specifieke map “Kylian” in de gedeelde map Video bekijken, maar verder niets mee doen (ja afspelen uiteraard)
3.   De rest van gedeelde mappen mag hij niet zien en al helemaal niet bewerken e.d.
4.   Dit moet ook werken als hij via zijn laptop een film zou willen bekijken

Ik heb een Ds414slim
Admin ben ik zelf, lid van groep admins en users
Guest is uitgeschakeld
Kylian is een door mij aangemaakte gebruiker en lid van de groep users
Zou iemand me kunnen en willen helpen dit correct in te regelen?
Vast bedankt Alexander