• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

OpenIndiana ACL's driving me nuts - Shared folder

P

PointandClick

Limp Gawd
Joined
Dec 6, 2008
Messages
383
Here's the situation. My account is typically the owner for all the files on my ZFS server. I want to setup certain folders like my Movies and TV shows so that they end up belonging to a "media" group with that group having r/w/x control. The primary purpose of this is so I can have a "xbmc" user for my XBMC setups that doesn't need access to my primary account.

Since there's no way to do this with traditional Unix permissions without changing the default umask's, which would effect all my other folders, I'm trying to wrap my head around ACL's.

I have a folder on my pool called "test". Setgid is enabled. I issue this command which, the way I understand it, should give the media group all permissions (except modifying ACL's) and it should be inherited by sub files/folders

Code: 
/bin/chmod A+group:media:modify_set:file_inherit/dir_inherit:allow test

Afterwards, the "test" folder shows the following ACL's:

Code: 
/bin/ls -vd test
drwxrwsr-x+  5 me     media          9 Jan 19 09:08 test
     0:group:media:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /synchronize:file_inherit/dir_inherit:allow
     1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     2:group@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/execute/read_attributes/read_acl
         /synchronize:allow
     3:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow

Looks good, but if I create a test file and look at it's ACL it only inherits read attributes

Code: 
/bin/ls -vd file7-rw-r--r--+  1 me     media          8 Jan 19 09:30 file7
     0:group:media:read_data/read_xattr/read_attributes/read_acl/synchronize
         :inherited:allow
     1:owner@:read_data/write_data/append_data/read_xattr/write_xattr
         /read_attributes/write_attributes/read_acl/write_acl/write_owner
         /synchronize:allow
     2:group@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
     3:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize
         :allow

Am I missing something here? Am I misunderstanding the way inheritance works?
 
Ok, I think I found what I was missing. I needed to set aclmode=passthrough and aclinherit=passthrough for my ZFS dataset. I'm not sure whether the aclmode setting is strictly needed, but I know the aclinherit is. Perhaps someone more knowledgeable than I can chime in on that.

Also, is there any negative effects of using the "passthough" mode?
 
I'm not aware of any "negative effects" of passthrough mode, but I guess it depends what would constitute a "negative effect" on your specific setup.
I'm only using mine for home use so although I have private filesystems for different users, I don't lose sleep at night wondering whether my parents have found a permissions loophole! If I were setting up a serious corporate server, I might be more inclined to fully research all the implications of setting a certain permission.

I mostly followed instructions and advice from the various manuals and blogs on the web that explained setting up ACLs, so I have both aclinherit and aclmode set to passthrough, and everything seems to work great.

As you have already gathered, you need aclinherit set to passthrough in your scenario, because:
... The default aclinherit property is restricted, which means that write_data and execute permissions are not inherited.
Click to expand...
http://docs.oracle.com/cd/E19253-01/819-5461/gbabx/index.html


I'm not so sure about aclmode. I've read this page, but IMO it's not explained very clearly..: http://docs.oracle.com/cd/E19082-01/817-2271/gbaaz/index.html

My interpretation is that aclmode seems to be more to do with whether the inherited permissions are modified after they are inherited, to suit the particular file. The alternative modes (discard and groupmask) seem to trim down the inherited permissions that are not applicable. If I'm wrong then I hope someone more experienced will correct me.
 
Might I suggest using Napp-it to control your OpenIndiana ZFS box?

It took me a couple of tries to set ACL permissions, but I got it figured out. For SMB shares, you want to leave it set to allow everyone full access. Then on the folder permissions, that is where you really set your ACL permissions
 
You're right that security really isn't that big of a concern since this is for a home file server. I just like to try to set things up "correctly" for lack of a better term as learning experience.

I have played around with Napp-it. It is a pretty slick tool. Again, however, if I can I prefer to learn to do things the manual way if at all possible so that I get a better understanding of how they work.

I think I have a decent understanding of ACL's now... at least I got it to do what I want. It's not terrible once you understand it, just overwhelming to go through and set them with the large list of options.
 
You must log in or register to reply here.
Back
Top