samba - Jul 2017 - Allow single sub-folder access on an otherwise prohibited share - why does the solution work?

Hi list,

I have managed to grant a specific user access to a sub-folder 
(sub-level 3 from the share's entry point, I think) on a Samba 4 share 
he/she is not allowed and not able to access in total/general. I tried 2 
different ways with one of them working. I'd like to discuss why that is.

For the sake of an example, let's say the share is for teaching material 
(exam templates, grade lists, etc.), where only a few people of our 
personnel have access. One person shall be granted access to a 
sub-folder some levels down the file system, where info material for a 
particular course is hosted, but ONLY that folder and its sub-folders.

This person is in the "Domain User" group but NOT in the
"Teaching"
group. The share can be accessed by "Domain Admins" and
"Teaching"
personnel only (-> via the share's Security settings; Share Permissions 
are set to "Full control" for "Everyone"). So usually,
access is denied
to that person.

Way 1 - not working:
- simply grant the person dedicated (not inherited) "Modify"
permissions
for the sub-folder in question

Way 2 - working:
- add the person to the "Teaching" group (which grants complete
access)
- create another group - let's say "Teaching_Users_restricted" -
and add
the person to it; DENY this group "Full control" to the complete
share's
file system - so again the person does not have access to any part of 
the share
- now grant the person dedicated (not inherited) "Modify" permissions 
for the sub-folder in question

Why is the second method working (and working as expected)? The only 
info I found on the web is that DENY takes precedence over ALLOW, which 
does not explain my finding, right?

Ole


-- 

Dr. Ole Traupe

Lab Manager

Technische Universität Berlin
Biopsychologie und Neuroergonomie
Institut für Psychologie und Arbeitswissenschaft

Biological Psychology and Neuroergonomics
Department of Psychology and Ergonomics

Postanschrift/Mail to:

TU Berlin / KWT-1
Dr. Ole Traupe
Fasanenstr. 1
10623 Berlin
GERMANY

Zimmer/Office: KWT-N, Eingang 1; 2. OG
Telefon/Phone: (+49) 030 314 79513
Fax: (+49) 030 314 79516

E-Mail:ole.traupe at tu-berlin.de
www.bpn.tu-berlin.de

>
> Why is the second method working (and working as expected)? The only info
> I found on the web is that DENY takes precedence over ALLOW, which does not
> explain my finding, right?
>
In Windows, explicit permissions take precedence over inherited
permissions, even inherited deny permissions.
https://technet.microsoft.com/en-us/library/cc783530(v=ws.10).aspx

Samba apparently does the same.

This wasn't a very good answer to the initial question. I presume you're
using acl_xattr, which I'm not overly familiar with (I use ZFS ACLs). In
general, users need the x-bit to be able to traverse the file tree in which
a share is located (in addition to whatever ACLs may be defined in the
xattr). Perhaps take a close look at both the ACL and the underlying
filesystem permissions. In theory, it's possible that when you added the
user to the teaching group, that particular group had the x-bit for the
share, then the final explicit ACL took precedence as you defined the
filesystem ACLs. Permissions can be tricky.

It's worth noting that with ZFS ACLs, IIRC, deny always takes precedence.

On Wed, Jul 5, 2017 at 9:00 AM, Andrew Walker <walker.aj325 at gmail.com>
wrote:
> Why is the second method working (and working as expected)? The only info
>> I found on the web is that DENY takes precedence over ALLOW, which does
not
>> explain my finding, right?
>>
>
> In Windows, explicit permissions take precedence over inherited
> permissions, even inherited deny permissions.  https://technet.microsoft.
> com/en-us/library/cc783530(v=ws.10).aspx
>
> Samba apparently does the same.
>

Am 04.07.2017 um 15:02 schrieb Ole Traupe via samba:
> I have managed to grant a specific user access to a sub-folder 
> (sub-level 3 from the share's entry point, I think) on a Samba 4 share 
> he/she is not allowed and not able to access in total/general. I tried 2 
> different ways with one of them working. I'd like to discuss why that
is.
The correct way to do this is to grant the user only the X right on only 
the folders above, and the RX or M right on the folder where user should 
have access.

icacls dir         /grant user:(np)(x)
icacls dir\subdir  /grant user:m

The user will not be able to do anything in dir, not even see subdir. 
The admin should create a shortcut to subdir, and place that shortcut 
somewhere where the user can click on it, for example on the users desktop.

Andrew, Klaus, let me first thank you for your hints and explanations, 
and apologize that I didn't respond in time! Actually, I simply forgot 
about having posted my question due to high work load in other areas.

Yes, denial takes precedence over permission, also in Windows/Samba, 
afaik. Which is why step 2 of my 2nd solution works.

And yes, explicit permissions take precedence over inheritance, which is 
why step 3 of my 2nd solution works. But to my intuition, this should 
apply to the first solution as well: granting explicit permissions 
(actually any explicit or implicit ACL mentioning of that user/group) 
ONLY for the folder in question.

The missing 'traverse' permission seems to be the culprit. Thanks to 
both of you!

Although I am a bit puzzled:
- step 1 (adding user to Teaching group, which has 'modify' permission 
for the whole share) obviously includes 'traversal'
- step 2 (adding user to Teaching_Users_restricted, being _denied_ 'full 
control' for the whole share) should also include the 'traversal'
Those two steps should cancel each other out, no?

In any way, just providing the 'traverse' permission for the above 
folders works perfectly. Thanks again!

Any yes, we are using shortcuts. But mapping a network drive to this 
particular sub-folder works, as well.

Ole



On 06.07.2017 18:44, Klaus Hartnegg via samba wrote:
> Am 04.07.2017 um 15:02 schrieb Ole Traupe via samba:
>> I have managed to grant a specific user access to a sub-folder 
>> (sub-level 3 from the share's entry point, I think) on a Samba 4 
>> share he/she is not allowed and not able to access in total/general. 
>> I tried 2 different ways with one of them working. I'd like to 
>> discuss why that is.
>
> The correct way to do this is to grant the user only the X right on 
> only the folders above, and the RX or M right on the folder where user 
> should have access.
>
> icacls dir         /grant user:(np)(x)
> icacls dir\subdir  /grant user:m
>
> The user will not be able to do anything in dir, not even see subdir. 
> The admin should create a shortcut to subdir, and place that shortcut 
> somewhere where the user can click on it, for example on the users 
> desktop.
>