Re: [cifs-discuss] idmap and groups

[Jordan Brown]

On 07/14/11 03:43, Chris Ridd wrote:


On 13 Jul 2011, at 20:55, Jordan Brown wrote:


They certainly aren't fake.  I agree that something looks wrong in the
handling of d and D.  I've passed that on to the ZFS team.


If it makes a difference, my pool is at version 22 and I'm using
OpenIndiana build 147. The odd behaviour with d and D may have been
fixed internally since the public onnv gate stopped getting updates.


It turns out that there's an interaction with the w bit on the directory; 
if neither d nor D is specified in the ACL then the w bit controls.  You 
have to use a Deny entry if you want to block delete but allow create. 
This is as specified in the NFSv4 RFC (which is where ZFS ACLs come from):

http://tools.ietf.org/html/rfc5661#section-6.2.1.3.2

Personally, I think that it's a mistake and the RFC ought to be changed, 
but right now it's working as intended in that particular case.


It does look like d (delete permission on the file itself) is broken in 
that even a Deny entry isn't effective.  I'm talking to the ZFS team about it.

___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss

Re: [cifs-discuss] idmap and groups

[Chris Ridd]

On 12 Jul 2011, at 18:18, Jordan Brown wrote:

 On 07/12/11 06:45, Chris Ridd wrote:
 # /usr/bin/ls -lV smb.txt -rwx--+  1 releng   dev   29 Jul
 12 13:09 smb.txt user:releng:rwxpdDaARWcCos:---:allow
 group:2147483648:rwxpdDaARWcCos:---:allow
 
 OK, first, note that the group ownership of the file is correct:  dev. What's 
 perhaps confusing you is that there's an *unrelated* group ACL entry where 
 you might have expected an entry for dev.

Right.

 Why is there a number instead of a name in the ACL? I note it is
 0x8000, which looks suspicious.
 
 Numbers 0x8000 and larger are magic.  A few right above 0x8000 are 
 reserved for some extra-special Windows special identities; the rest are 
 ephemeral IDs used for Windows users with no corresponding UNIX user. 
 (Mostly those appear in Active Directory environments.)  0x8000 itself is 
 hardwired to be the local system account, SID S-1-5-18, sometimes called 
 SYSTEM or Local System.
 
 If you put ad in your nsswitch.conf passwd and group lines, these special 
 IDs will get names associated with them.

We're not using AD at all - just LDAP with an RFC 2307bis-ish schema. I could 
populate it with some of these specials, but it doesn't seem useful.

 You can also manually look them up using idmap(1M):
 
 $ idmap show gid:2147483648
 gid:2147483648 - sid:S-1-5-18
 
 $ idmap show gid:2147483648 winname
 gid:2147483648 - wingroup:Local System
 
 Now, how did that get into your ACL?

Indeed!

 Remember that Windows ACLs are usually derived from the parent directory, if 
 it has (as it usually does) the inherit bits set.  With no inherit bits set 
 in the parent, a default ACL is used:  all permissions to the user who 
 created the file, and all permissions to the local system account. It looks 
 like you're getting that case, that the parent directory doesn't have inherit 
 bits set.

Ah, that was the clue I needed.

You were right, the parent directory didn't have file_inherit or dir_inherit 
set at all. In fact I'm not really sure the ACLs on the parent directory were 
really being used - owner@ was not granted d or D permissions yet was still 
able to delete files. Are these ACLs faked up?

Adding inheritance to those ACLs wasn't useful, and replacing them entirely 
with ones that gave full control and with inheritance set looks like (fingers 
crossed) it is doing the job. As a bonus it means those reserved values aren't 
visible.

 By the way, please don't rely on the reserved values at 0x8000.  We don't 
 actually store them in the file system - what gets stored is the SID - and we 
 might change how they're allocated.

Noted.

Thanks *very* much for the comments!

Chris
___
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss