Setting ACLs when creating files from Windows

[Corinna Vinschen]

On Jul 30 16:15, Volker Lendecke wrote:
> On Fri, Jul 18, 2008 at 02:00:15PM +0200, Corinna Vinschen wrote:
> > - Why does legacy_sid_to_uid fail?  The user with the above SID has been
> >   authenticated correctly and is mapped to a unix user:
> >   
> >   [2008/07/18 13:12:45, 5] smbd/uid.c:change_to_user(273)
> >     change_to_user uid=(500,500) gid=(0,11125)
> > 
> >   Why is the SID not mapped to that uid?
> 
> Good question. We'd need a debug level 10 log of that.

To the list?  Or PM?

> > - I'm looking for a generic solution to this problem from a Windows
> >   application perspective.  Except that the underlying system is
> >   a Samba share, I heve no further knowledge about the underlying
> >   system.  I don't know which securty is used and I have no idea
> >   about the SIDs used for UNIX users and groups.  I only know the
> >   SID of my Windows environment.
> > 
> >   Is there any chance to have a generic solution, except for ignoring
> >   file permissions when creating files on Samba?
> 
> In theory, creating files with security descriptors should
> work fine. However, if you want to create files with
> posix-style permissions, one way could be to use the EA path

POSIX-like permissions works fine, as long as the user and group SID
is the UNIX user/group SID.  If I use the Windows user and group,
it fails, apparently because the mapping from the Windows SID to the
UNIX user uid fails in legacy_sid_to_uid.

Does that only work with winbind running, maybe?  What I'm looking for
is a mapping from the Windows user who has authenticated and the UNIX
user it's mapped to in smbusers.  This only seems to work in
change_to_user, but not in legacy_sid_to_uid.  And the way back, from
uid/gid to SID doesn't seem to work at all.

> and pass the permission info along. This would require a
> Samba code change however.

Yes, that's the long term idea.  However, the SID<->uid/gid mapping
is still a problem.  With NFS, you can simply set the permission bits
at NtCreateFile time.  The user is the one you're mapped to using
the user mapping service (whichever is used).

> > - Last but not least, in the first case, where the descriptor is give
> >   to NtCreateFile, why is the file not removed even though NtCreateFile
> >   failed?
> 
> That's a Samba bug.

Uh, ok.  Good to know.  Fortunately my workaround to create the file
with default SD and to set the permission bits afterwards works fine
for the time being.


Thanks,
Corinna