SMB shares and permissions

[ip9]

Hi everyone,

I've been fiddling around (and searching the docs, the forum, ...) for the last few days to figure out, how to handle permissions in SMB shares.
Actually it's even two topics.

• Probably the easy one:
  • I'd like to use "Access Based Share Enumeration" for some of the shares...
  • I found out, that this is based on the "Share ACLs".
  • Editing Share ACLs shows an editor that seems to be focused on Active Directory SIDs.

My question on this one is: can this be done with local users - and if so: how...

• Shares for different, overlapping groups.

let's assume we have three users A, B and C; all of them are member of group ABC; A and B are in AB, ...
and the following shares:
Share AB should only be accessible (modify or full control) for users A and B
Share AC should only be accessible (modify or full control) for users A and C
Share BC should only be accessible (modify or full control) for users B and C
Share ABC should only be accessible (modify or full control) for users A, B and C

The only way I found to do this was to set "Auxiliary Parameters " in each share's settings to
force group = AB #[replace by respective group for each share]
create mask = 0770
as otherwise the files would allways be created with a mask of 0700 and owner and primary group of the creating user - and thus beeing inaccessible by everone else.

This kind of works, but I can't help - it doesn't seem to be the right way to do it.
Any suggestion on what would be a better way to configure those shares?

Ingo

 

[anodos]

You just assign relevant permissions to local groups. Auxiliary parameters should never be required.

 

[anodos]

It does seem that you should probably create more groups to appropriately reflect desired access rights to your shares, e.g. groups AB, AC, BC, and ABC. Then make users members of the groups and grant the groups permissions to the shares.

 

[ip9]

Anodos, thanks for your reply...
and the confirmation that auxiliary parameters shouldn't be needed and the expected behaviour is more or less what I expected it to be.

The "additional" groups are all there.. one for each share that has individual permission

Unfortunately it isn't like that for me, even though I tried different settings for "Share Settings -> Purpose" and file system ACLs (preset and individual)

No matter what settings I used, all files are written with 0700 as mask and owner/group set to the user/his primary group of the user creating the file.

Is there a guide on what presets/settings to use?

Ingo

 

[anodos]

No matter what settings I used, all files are written with 0700 as mask

Depending on server configuration, this may be something being sent by your SMB client (though I can't say for certain because 0700 doesn't tell me anything about ACL configuration after file creation). Is dataset ACL type POSIX or NFSv4?

owner/group set to the user/his primary group of the user creating the file.

Yes, this will always be the case. It's how the Linux works (with a few caveats).

 

[ip9]

thanks anodos for jumping in, but unfortunately I'm still lost.

hm... ok, I'll try to start fresh and keep it simple and as much "default" as possible.

• created new dataset, mostly default, but set share type to SMB
• in ACL editor
  • I set owner to a user I created specifically as "share owner" and
  • owner group to a group containing users A and B
  • set ACLs to preset ACL "NFS4_RESTRICED"
  • marked both checkboxes "apply permissions recursively/to child datasets"
• added a new SMB share using the new dataset, keeping "purpose" set to "Default share parameters", didn't change share permissions

Both users were able to create documents and read, edit, delete .. those documents they created.
But both users didn't have any access to the document the other user created.
My expectation (and requirement) is that all members of a group

Now I went back to filesystem ACL editor and changed permissions using preset "NFS4_OPEN".
Now both users could read, write, edit, delete all files in the share (so far so good) - but user C (not member of the group set as owner group) could also read, write, edit all files...

Unfortunately both variants aren't meeting my requirements. :-(
Those would be users A and B (or more precise: users of a specific group) should be able read, write, modify, delete all files in the share - no matter if they created them ore someone else.
But user C (or again more precise: all users not in that specific group) shouldn't have access at all.
In my understanding this isn't anything special, but a pretty normal thing...

I was able to do achieve that by using the auxiliary parameters mentioned in the first post - but as you mentioned - this isn't the way it is supposed to work...

Setting that "common" group as the primary group for users A and B would work for that one share... but as described in the first post (for the sake of keeping it simple) there will be three shares AB, AC and CB - so there won't be a common group for all three of them..

Anyone any idea what I can do to create those shares with the described set of permissions?


Ingo

 

[ip9]

did some digging around on my qnap - they seem to handle it with a combination of

• all users have the same primary group (everyone)
• setting those two masks in the global part of smb.con
  • directory mask = 0777
  • create mask = 0777
• controlling access permissions to the share on share access level with those to entries in the share's section in smb.conf
  • write list = ..., @"test"
  • valid users = "..., @"test"

not the most flexible way do to it, but it gets you there (in many cases)

 

[anodos]

Are you setting permissions for group@ in the NFSv4 ACL or are you assigning permissions explicitly to the groups. The group designated by group@ will change as different users create files / dirs based on user's primary group (which will change how access is evaluated).

You can set up to 64 entries in the NFSv4 ACL in SCALE. So just explicitly define what you want.

 

[ip9]

thanks... this did the trick.
Seems I completely misunderstood the functionality of the group@ thing (my guess was, it sets all permissions to the share's owners-group - I was obviously wrong)

with your suggestion I ended up with a working set of ACLs - it looks like in the screenshot below...

• everyone in the group iph can read, create, change and delete files and folders - no matter who created them.

thanks a huge lot for your help and patience.
(and if I may suggest something - make something like that a ACL preset...)

Ingo

 

[anodos]

There is an API to create new presets, it's just not exposed in the webui. In reality though, it's probably best to also include owner@ and group@ entries. They're used to synthesize a POSIX mode (which is returned in stat(2) calls from applications). Some poorly designed apps and scripts will do their own incomplete permissions checks based on POSIX mode (i.e. aren't ACL-aware).

So:
owner@ - full control
group@ - (modify or whatever you want)
iph - full control

And make sure you set INHERIT flag on them all.

 

[ip9]

thanks again - makes sense...
did as you suggested and so far all my "testcases" worked fine