Setting ACLs when creating files from Windows

[Corinna Vinschen]

On Aug  1 15:16, Volker Lendecke wrote:
> On Thu, Jul 31, 2008 at 10:45:27PM +0200, Corinna Vinschen wrote:
> > Sorry.  I attached now what happened when I cd'ed to the share for the
> > first time.  I'm somewhat puzzled that the Windows user SID never shows
> > up in the log.  Is it never transferred to the server?!?
> 
> No, only the name is at session setup time.

Oh, hmm.

> 
> > > What does "rpcclient localhost -U% -c 'lookupnames corinna'"
> > > say when run on the Samba box?
> > 
> > $ rpcclient localhost -U% -c 'lookupnames corinna'
> > corinna S-1-22-1-500 (User: 1)
> 
> Ok, here we go. That's what you would have to set in the sd.

Which is exactly the problem...

> > Oh and, even with winbind, there doesn't seem to be a way to map
> > a Windows user to an arbitrary, already existing UNIX account.
> 
> ?? Doesn't "username map" work for you?

It does, but apparently not the way I imagined/hoped for.

> > > Hmmm. Difficult. S-1-22-1-<uid> should always work, but how
> > > do you know your uid then? There's also a "lsa who am I"
> > 
> > I don't know my uid.  Not programatically.  I'm using the SID of the
> > current Windows user and the SID of its primary group in the security
> > descriptor in a call to NtCreateFile.
> 
> Without both boxes being member of the same domain, we are
> always talking about two different users. They happen to
> have the same password, but apart from that they don't have
> anything in common.

That's the problem.  Since the Samba share is running on a OS which
has no native notion of SIDs, I expected that there's a way to do
a mapping from a remote SID to a local uid/gid, especially for the
case where no domain is available, but you only have a set of 
standalone machines running in the same workgroup.

> > The mapping to the uid/gid is done on the Samba side.  For some reason
> > it's only done at authentication time, but the mapping doesn't work in
> > the later call to NtCreateFile with the aforementioned security
> > descriptor.  I would expect that Samba knows the SID of the
> > authenticated Windows user/primary group and maps them transparently to
> > the UNIX user/group in all subsequent calls where the Windows SID is
> > used.  Provided that Samba gets the SIDs (the entire user token?) from
> > the incoming Windows client at one point.
> 
> No, we never get that. What we get is the qualified user
> name and the credentials, that's it. Windows never sends
> anything but that information.

That's really unexpected, but I guess I have to live with that and...

> > Maybe, but I'm rather wondering why the SID<->uid/sid mapping doesn't
> > work transparently from a Windows client POV which has no idea that the
> > remote machine is a Samba server, rather than a native Windows server.
> 
> Well, that's just how the protocol works. Sorry.
> [...]
> But wait a second -- what you could do is to create the file
> without an sd, ask for the owner sid via querysecdesc and
> then set the sd using that sid. But that's a 3-step process
> instead of one.

That's exactly what my workaround for Samba is doing now, as I
described at the start of this thread.  Looks like I have to stick
with that.


Thanks for looking into this,
Corinna