Samba 2.2 and "nt acl support = no"

[acherry at pobox.com]

Hello-

We've been working on upgrading our servers from Samba 2.0.6 to Samba
2.2.1a and have run into a problem with a change in Samba's behavior
when NT ACL support is turned off.  I was hoping someone on the list
could provide some insight about what is going on.

First, some background.  On our main file servers, we've been running
Samba 2.0.6 with NT ACL support turned off ("nt acl support = no" in
smb.conf).  This is becuase our primary packaging tool, Wise
InstallMaster, produces installable packages which check the security
on files before overwriting them, and will refuse to overwrite the
files if the SID of the NT domain user installing the package does not
match any of the SIDs on the Samba server that have write access to
the files.  (This is really a design flaw in the Wise product, which
uses NTAccessCheck() to check the permissions, but since it doesn't
cause problems on a typical NT domain with NT servers, they don't
seem to be inclined to fix it). I've gone into detail about this in a
past post, but the crux of the issue is that the Samba server has its
own SIDs, while the Wise executables are expecting to see NT domain
SIDs.

Under Samba 2.0, when "nt acl support = no" is set in smb.conf, an
NTTRANS_QUERY_SECURITY_DESC call would return a "bogus" SID that
showed the "Everyone" user as having read/write access to the file or
directory being queried.  This is not the case under 2.2.1a; I'm
guessing that the server is somehow telling the client that it doesn't
support ACLs (I'm only guessing this based on the absence of the
Security tab when I bring up the file properties dialog in Windows
Explorer). However, the Wise packages now fail whether or not "nt acl
support" is turned on, and even when "nt acl support = no", a network
snoop shows an NTTRANS_QUERY_SECURITY_DESC transaction occuring.
Somehow the client is still querying and receiving a security
descriptor with owner/group SIDs and a DACL corresponding to
user/group/other permissions.

Is this the correct behavior?  Is the client somehow supposed to know
to not ask the server for security information?  Any ideas?

Any information that anyone can provide would be greatly appreciated!

Thanks...

-Andrew Cherry
 UNIX System Admin
 Cummins, Inc.