Setting ACLs when creating files from Windows

[simo]

On Thu, 2008-08-07 at 15:32 +0200, Corinna Vinschen wrote:
> On Aug  7 07:48, simo wrote:
> > On Thu, 2008-08-07 at 12:12 +0200, Corinna Vinschen wrote:
> > > I am having a Windows DC, but that's not really the point.  What I'm
> > > looking for is something which should work also for users which just
> > > have a Windows client OS and a Linux machine sitting under their desk,
> > > whihc no domain setup at all.  The idea was that there's an automatic
> > > mapping from the user and primary group SIDs in the Windows user token
> > > of the authenticating user to a uid/gid pair on the Samba machine, using
> > > the information in the usermap file.  However, since Volker mentioned
> > > that there are no SIDs transferred from the Windows client machine to
> > > the server at authentication time, there's not much chance that this
> > > would work as I had hoped for.
> > 
> > If there is no domain setup, the SID you use on the windows client has
> > no meaning for the samba server. The Domain part will just be alien.
> > Only a domain setup where all the players are member of the same domain
> > (or trusted set of domains) can use directly SIDs, as in the case both
> > parties have a way to understand what they mean.
> > 
> > To be honest, windows machines can store in the file system just any SID
> > handled to them, but they will never do any mapping server side.
> > So if you take 2 windows client and try to set the SID of user Foo on
> > client 1 on client 2, user Foo of client 2 will not actually be able to
> > access the resource, as the SID will not match.
> > 
> > In general it's best if you avoid assuming what SID belong to whom on
> > network communications.
> 
> Well, in theory I don't care if it's a network FS or a local FS.
> Cygwin's open() code simply tries to create files with a SD which
> contains the current user, its primary group and an Everyone ACE,
> regardless of the underlying FS.  This works fine on local and remote
> Windows filesystems, just not on Samba which needs the described

Yes but what happens on the remote windows filesystem ?
Do you just set an arbitrary SID there? This will work, but is probably
not what your users want.

> workaround, and on NFS, which uses an entirely different mechanism, the
> extended attributes approach.  It's not exactly Samba's fault, it's just
> annoying that so many different code paths are required to get the same
> result on different filesystems.  I had hoped for a simpler approach.

You should probably treat a remote windows filesystem and samba the same
way, unless your machines are in a domain and you are using domain users
I think you are setting unwanted SIDs on the remote windows machine.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>