zfs discuss - Oct 2010 - file-inherit and dir-inherit at toplevel of ZFS CIFS share

It looks like permissions don''t descend properly from the top-level
share
in CIFS; I had to set them on the next level down to get the intended
results (including on lower levels; they seem to inherit properly from the
second level, just not from the top).  Is this a known behavior, or am I
confused and setting myself up for trouble later?

More broadly, is there anything good about "best practices" for using
ACLS
with ZFS and CIFS shares?  For example, there are so many defined
attributes, some of them with the same short-form letter (I think one is
for directories and one is for files in that case, but that''s not
documented that I can find), that I find myself wondering what "standard
bundles" of permissions would be useful.   Is it generally better to have
separate permissions to inherit for files and directories, or can most
things you want be accomplished with just one?

Back to specifics again -- I was running into a problem where a user on
the Solaris box could rename a file or directory, but an XP box
authenticating as the same user could not.  This was the one that seemed
to be solved by setting the permissions again one level down (dunno what
happens with new top-level items yet).  Is this normal behavior of
something that makes sense?  It''s terribly weird.  (In windows, I could
right-click and create the "new directory" or whatever, but when I
then
filled in the name I wanted and hit enter, I got a permission error.  I
could just leave it named "new directory", though.  And I could rename
it
on the Linux side as the same user that failed to rename it from the
Windows side.)

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On 10/25/10 07:23 AM, David Dyer-Bennet wrote:
> It looks like permissions don''t descend properly from the
top-level share
> in CIFS; I had to set them on the next level down to get the intended
> results (including on lower levels; they seem to inherit properly from the
> second level, just not from the top).  Is this a known behavior, or am I
> confused and setting myself up for trouble later?
You probably have simple UNIX permission set on the top-level
directory.  Use ACLs not specific UNIX permissions.  If you''re
not comfortable with setting ACLs via chmod, start with one of
the following and tune from Windows:

	/bin/chmod A=everyone@:full_set:fd:allow /pool/fs
or
	/bin/chmod A=owner@:full_set:fd:allow /pool/fs
	/bin/chmod A+=group@:read_set/execute:fd:allow /pool/fs
	/bin/chmod A+=everyone@:read_set/execute:fd:allow /pool/fs
> More broadly, is there anything good about "best practices" for
using ACLS
> with ZFS and CIFS shares?  For example, there are so many defined
> attributes, some of them with the same short-form letter (I think one is
> for directories and one is for files in that case, but that''s not
> documented that I can find), that I find myself wondering what
"standard
> bundles" of permissions would be useful.   Is it generally better to
have
> separate permissions to inherit for files and directories, or can most
> things you want be accomplished with just one?
The attributes should all be described in the chmod(1) man page.
> Back to specifics again -- I was running into a problem where a user on
> the Solaris box could rename a file or directory, but an XP box
> authenticating as the same user could not.  This was the one that seemed
> to be solved by setting the permissions again one level down (dunno what
> happens with new top-level items yet).  Is this normal behavior of
> something that makes sense?  It''s terribly weird.  (In windows, I
could
> right-click and create the "new directory" or whatever, but when
I then
> filled in the name I wanted and hit enter, I got a permission error.  I
> could just leave it named "new directory", though.  And I could
rename it
> on the Linux side as the same user that failed to rename it from the
> Windows side.)
If you want a Windows-like permission experience: use ACLs rather than
perms and ensure ''fd'' is set when you set that initial ACL
(see above).

Alan