Probleem met hidden user Auto-Sub

[Ben(V)]

@Matr!x

Als je toch een nieuw package gaat maken voor autosub misschien kun  je ook het aanmaken van de "user" aanpassen.
Nu wordt er een hidden user "autosub-bootstrapbill" aangemaakt, maar als het met het synouser commando wordt gedaan wordt er een normaal zichtbare user aangemaakt. Zou voor veel minder problemen met het zetten van rechten geven.

Hier een stukje uit de DSM Developer Guide

Code: [Selecteer]

The synouser command line tool can help you create user accounts.
This account is visible in DSM, and end users are able to edit the account settings in Control Panel.
However, the accounts will not be editable in DSM settings if they are created via methods other than synouser and with UID less than 1024.

synouser ––add username password "" expired email privilege



[Matr1x]

Het maken van SPK is even blijven liggen en volgende week ben ik weer in de US. Nog even geduld dus.

Enne, we volgen met het maken van een SPK een beetje de standaard die SynoCommunity ook volgt. Dus gewoon een verborgen gebruiker die overigens nu gewoon autosub kan heten (aangezien het oorspronkelijke pakket niet meer bestaat).

[Ben(V)]

Ook bij de synocommunity is een disscussie gaande of er niet gewoon in DSM zichtbare users gebruikt moeten worden of anders een aparte groep.
Het probleem met hidden users is dat je die vanuit DSM alleen rechten kunt geven via de groepsrechten en dan hebben meteen alle users die rechten.
Dit is niet voor niets door Synology toegevoegd en in hun Developers Guide beschreven.

[DrBean]

De mogelijkheid tot het creëren van users via CLI komt simpelweg voort uit de structuur van het (Linux) OS, waarin veel UI keuzes/wijzigingen op de achtergrond via de CLI worden uitgevoerd.
Het synouser commando bestaat dan ook al een hele tijd, maar is niet heel bruikbaar voor packages (die voornamelijk als service moeten draaien).
Binnen SynoCommunity is dit vaker besproken, en iedere keer is de uitkomst dat zichtbare 'gewone' users meer problemen opleveren dan dat het oplossingen biedt.

Mocht Synology de mogelijkheid bieden om systemusers te maken, en deze zichtbaar te maken in de UI met een rits aan beperkingen, dan wordt het interessant, iig voor SynoCommunity packages. Tot die tijd zijn de 'users' groep (en mogelijk het gebruik van een groep per set gelijksoortige packages) -voor ons- het enige bruikbare alternatief.

[Ben(V)]

Begrijp ik allemaal.
Maar vooral packages die data downloaden leveren vaak problemen op voor mensen die meerdere users hebben en die ze de toegang tot die data willen ontzeggen.
Ze zitten allemaal in de group users en als je via groepsrechten toegang hebt, helpt dichtzetten op user nivo niet meer.
Zoals je al zei een aparte group hiervoor zou al een hoop oplossen.

[DrBean]

Ze zitten allemaal in de group users en als je via groepsrechten toegang hebt, helpt dichtzetten op user nivo niet meer.

Euh? Dit is wsl niet meer de juiste thread om dit te bespreken, maar dat is niet juist. Deny rechten gaan juist _voor_ alle andere rechten.
Stel: user 'testuser' staat in de groep 'users'. Groep 'users' heeft RW-rechten op map 'download'. Dan heeft natuurlijk 'testuser' RW rechten op 'download'.
Zet deny voor de 'testuser' op map 'download', of zet de 'testuser' in groep 'geentoegang', met op de groep 'geentoegang' een deny op de map 'download': dan kan 'testuser' niet in de map.

/edit: beetje onleesbaar geheel zo, maargoed. DSM5 laat ook een preview zien van de rechten die gelden voor een user en een bepaalde map: die zal bovenstaande ook bevestigen.
Nog een overweging waard: gebruik de users groep niet om rechten te zetten/te ontnemen. Heb je veel users die je op basis van bepaalde criteria toegang wilt geven of ontzeggen tot resources (mappen, applicaties etc), gebruik dan je eigen groepen- en rechtenstructuur, en laat de groep users voor wat het is.

[Matr1x]

Ik heb het draadje maar even gesplitst, omdat dit toch wel een interessante discussie is met bruikbare informatie.

Ik ben het eens met Ben(V) (en SynoCommunity) dat er een gewone gebruiker van maken problemen gaat geven. Je kunt deze gebruiker dan aanpassen, waardoor straks het pakket niet meer werkt. Of een pakket kan dan een trojan worden door een gebruiker aan te maken waar je mee kunt aanloggen. Het gaat alleen werken als je speciale gebruikers kan aanmaken, met beperkte rechten:

Mocht Synology de mogelijkheid bieden om systemusers te maken, en deze zichtbaar te maken in de UI met een rits aan beperkingen, dan wordt het interessant, iig voor SynoCommunity packages.

[Ben(V)]

Ik geef me gewonnen. Jullie argumenten zijn steekhoudend.
Een groep voor package users zou ik nog steeds handig vinden, maar ik geef toe dat het ook kan door een eigen groep voor je normale gebruikers aan te maken.

@DrBean
Je zult ongetwijfeld gelijk hebben. Ik dacht altijd dat toegang geven boven deny ging.
Zal het zelf nog wel eens uitproberen, zo eigenwijs ben ik wel

[DrBean]

Ik dacht altijd dat toegang geven boven deny ging.
Zal het zelf nog wel eens uitproberen, zo eigenwijs ben ik wel

Als je het tabblad 'Permissions' opent van een user, dan staat onderaan dat dialoogvenster de zin: "Permissions priority: NA > RW > RO". Daar kun je nog een vierde optie bij bedenken: "not set" (geen enkel vinkje), wat de laagste prioriteit heeft. Een expliciete NA (deny) heeft dus altijd de hoogste prioriteit.
Ik geef toe dat het niet handig is dat je een expliciete deny op een map moet zetten, maar dat komt omdat Synology een user altijd lid maakt van de users groep (wat z'n oorsprong weer heeft in de historie van DSM)

Over de groep per package/per set vergelijkbare packages: dat lijkt inderdaad het meest haalbare tot nu toe. Als het eerste SC-package met die opzet beschikbaar komt en geen praktische problemen oplevert, dan ligt het voor de hand dat meer packages zullen volgen. Erg belangrijk daarbij is backwards compatibility bij het upgraden van bestaande installaties, dus we kunnen het gebruik van de users groep niet zonder meer loslaten.