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 >> 0x80000000, which looks suspicious. > > Numbers 0x80000000 and larger are magic. A few right above 0x80000000 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.) 0x80000000 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 0x80000000. 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
