Setting ACLs when creating files from Windows

Hi,

I'm puzzeling over this problem for some time now. So far I need
a special hack in Cygwin for Samba, probably because I simply don't
understand something about the user mapping correctly.

My current situation is, I have a Samba server (3.0.30) which is a domain member machine. In smb.conf, security is set to domain. There's
no winbindd running. Before I set up the domain, I had the same problem
using security = server with the server being another Windows machine in
the same workgroup.

Usually when creating and changing files on the Samba shares, it
works fine, as long as creating the file uses a NULL security descriptor.

However, when Cygwin tries to create a file, it checks if the underlying
filesystem supports ACLs, and if so, it tries to set the ACL immediately
to correct PSIX permissions for the local user, along these lines (and
very simplifed):

DESCRIPTR *sd = NULL;
if ((open_flags & CREATE)
&& (fs_flags & FS_PERSISTENT_ACLS))
sd = ()
NtCreateFile (&fhandle, , sd, );

The ACL created for this case is equivalent to typical PSIX permissions,
and consists of three entries:

- SID of current windows user
- SID of user's primary group
- SID for "Everyone"

The problem is, when creating a file this way, the NtCreateFile call
fails with STATUS_ACCESS_DENIED. But, the file *has* been created,
with default permissions and owned by the mapped unix user and group.
For testing purposes I changed the above code to

SECURITY_DESCRIPTR *sd = NULL;
if ((open_flags & CREATE)
&& (fs_flags & FS_PERSISTENT_ACLS))
sd = ()
NtCreateFile (&fhandle, , NULL sd, );
NtSetS (fhandle, ALL_SECURITY_INFRMATIN, sd);

Now the NtCreateFile call succeeds, but the NtSetS call
fails with STATUS_ACCESS_DENIED.

The smbd logfile contains this log entry:

[2008/07/18 13:12:45, 10] (1260)
LEGACY: mapping failed for sid

Here are my questions:

- 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?

- 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?

- 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?


Thanks in advance,
Corinna

Ping?


Corinna

Jul 18 14:00, Corinna Vinschen wrote:
Hi,

I'm puzzeling over this problem for some time now. So far I need
a special hack in Cygwin for Samba, probably because I simply don't
understand something about the user mapping correctly.

My current situation is, I have a Samba server (3.0.30) which is a domain member machine. In smb.conf, security is set to domain. There's
no winbindd running. Before I set up the domain, I had the same problem
using security = server with the server being another Windows machine in
the same workgroup.

Usually when creating and changing files on the Samba shares, it
works fine, as long as creating the file uses a NULL security descriptor.

However, when Cygwin tries to create a file, it checks if the underlying
filesystem supports ACLs, and if so, it tries to set the ACL immediately
to correct PSIX permissions for the local user, along these lines (and
very simplifed):

DESCRIPTR *sd = NULL;
if ((open_flags & CREATE)
&& (fs_flags & FS_PERSISTENT_ACLS))
sd = ()
NtCreateFile (&fhandle, , sd, );

The ACL created for this case is equivalent to typical PSIX permissions,
and consists of three entries:

- SID of current windows user
- SID of user's primary group
- SID for "Everyone"

The problem is, when creating a file this way, the NtCreateFile call
fails with STATUS_ACCESS_DENIED. But, the file *has* been created,
with default permissions and owned by the mapped unix user and group.
For testing purposes I changed the above code to

SECURITY_DESCRIPTR *sd = NULL;
if ((open_flags & CREATE)
&& (fs_flags & FS_PERSISTENT_ACLS))
sd = ()
NtCreateFile (&fhandle, , NULL sd, );
NtSetS (fhandle, ALL_SECURITY_INFRMATIN, sd);

Now the NtCreateFile call succeeds, but the NtSetS call
fails with STATUS_ACCESS_DENIED.

The smbd logfile contains this log entry:

[2008/07/18 13:12:45, 10] (1260)
LEGACY: mapping failed for sid

Here are my questions:

- 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?

- 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?

- 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?


Thanks in advance,
Corinna

Wed, Jul 23, 2008 at 12:22:20PM +0200, Corinna Vinschen wrote:
Ping?

:-)

There's also your other mail in my inbox. At least I am
pretty busy, sorry :-)

Volker

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)


aHL7xYn+KcEG3LvMWpZGAqs=
=Bgdt
PGP SIGNATURE

Jul 24 00:03, Volker Lendecke wrote:
Wed, Jul 23, 2008 at 12:22:20PM +0200, Corinna Vinschen wrote:
Ping?

:-)

There's also your other mail in my inbox. At least I am

You mean, the one about the NFS-like extended attribute API?

pretty busy, sorry :-)

No worries,
Corinna

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.

- 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
and pass the permission info along. This would require a
Samba code change however.

- 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.

Volker

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)


kGwseYNKUTV7+2oFGf3Bs=
=qWN9
PGP SIGNATURE

Jul 30 16:15, Volker Lendecke wrote:
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? 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

PSIX-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

Wed, Jul 30, 2008 at 07:26:48PM +0200, Corinna Vinschen wrote:
Good question. We'd need a debug level 10 log of that.

To the list? PM?

PM if you like.

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

yes. ID mapping is the most controversial topic
that the Samba Team fights to get right for more than 10
years now, and even internally we completely disagree how
this should work. But that's another thread :-)

Volker

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)


g3docYtYh/S0is35i8aUK94=
=+oHn
PGP SIGNATURE

Jul 30 22:10, Volker Lendecke wrote:
Wed, Jul 30, 2008 at 07:26:48PM +0200, Corinna Vinschen wrote:
Good question. We'd need a debug level 10 log of that.

To the list? PM?

PM if you like.

List is fine. A level 10 log is just a lot of stuff and I wasn't sure
everybody would like it. The log of the complete operation is attached.

To explain what's going on, I reverted my Samba patch in Cygwin and
called `echo foo xxx'. What you see in the log is that Cygwin first
tries to find out if the file exists. To accomplish transparent
handling of .exe and .lnk (shortcuts as symlinks) suffixes, Cygwin tests
first if "xxx" exists and, if not, if "xxx.exe", "xxx.lnk" or (for
historical reasons) "xxx.exe.lnk" exists. Then Cygwin fetches file
system information.

When creating the file, NtCreateFile is called with a security
descriptor containing a DACL with three ACEs, the current Windows user
(), the user's primary
group () and Everyone
(S-1-1-0).

That's all. Apparently Samba knows to switch to the local UNIX user
corinna from the incoming request and creates the file as that user.
But eventually, in the call tyo set_nt_acl, legacy_sid_to_uid doesn't
know about the user mapping anymore and fails.

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

yes. ID mapping is the most controversial topic
that the Samba Team fights to get right for more than 10
years now, and even internally we completely disagree how
this should work. But that's another thread :-)

:)


Thanks for your help,
Corinna

Thu, Jul 31, 2008 at 10:35:46AM +0200, Corinna Vinschen wrote:
That's all. Apparently Samba knows to switch to the local UNIX user
corinna from the incoming request and creates the file as that user.
But eventually, in the call tyo set_nt_acl, legacy_sid_to_uid doesn't
know about the user mapping anymore and fails.

The problem very likely is that
is the SID of
user corinna on the workstation you're coming from, which
has nothing to do with the user corinna on the Samba box. If
you do a "net getlocalsid" on the samba box, you will
probably get a different SID prefix than
You might want to
do a lookupname() (don't know the API call in win32) against
the samba box before choosing the SID to set in the sd.

Volker

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)


fjSlrsux31elGaXQDkM4yys=
=07VB
PGP SIGNATURE

Thu, Jul 31, 2008 at 09:49:51PM +0200, Corinna Vinschen wrote:
Why not? The user with sid
has authenticated itself and is mapped by Samba to the user with uid 500.

Not sure about that. You did not post the session setup part
of the connection, there this would have been visible.

Files are created as that user with uid 500. Why is that mapping not
transparent when creating files with security descriptors using the SID
which has been mapped to the uid formerly? That's hard to understand.
Isn't that what the smbusers file is supposed to accomplish?

What does "rpcclient localhost -U% -c 'lookupnames corinna'"
say when run on the Samba box?

you do a "net getlocalsid" on the samba box, you will
probably get a different SID prefix than
You might want to
do a lookupname() (don't know the API call in win32) against
the samba box before choosing the SID to set in the sd.

How shall I know what UNIX user my Windows user is mapped to? If
smbusers contains a mapping like "foo = bar", and a UNIX user bar
doesn't exist, how should I ever find out that I have to ask for a UNIX
user foo? Sure, winbind seems to solve this problem, but that works
only for domains, not for standalone machines.

Hmmm. Difficult. S-1-22-1-<uidshould always work, but how
do you know your uid then? There's also a "lsa who am I"
call that gives you the name that you authenticated as, but
as you say this might not be sufficient either. This btw is
exactly where some RPC programming might come in extremely
handy :-)

Volker

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)


5p257iKK5z3N+FtIUYa/zhU=
=B2Tc
PGP SIGNATURE

Jul 31 21:49, Corinna Vinschen wrote:
Jul 31 19:09, Volker Lendecke wrote:
Thu, Jul 31, 2008 at 10:35:46AM +0200, Corinna Vinschen wrote:
That's all. Apparently Samba knows to switch to the local UNIX user
corinna from the incoming request and creates the file as that user.
But eventually, in the call tyo set_nt_acl, legacy_sid_to_uid doesn't
know about the user mapping anymore and fails.

The problem very likely is that
is the SID of
user corinna on the workstation you're coming from, which
has nothing to do with the user corinna on the Samba box. If

Why not? The user with sid
has authenticated itself and is mapped by Samba to the user with uid 500.
Files are created as that user with uid 500. Why is that mapping not
transparent when creating files with security descriptors using the SID
which has been mapped to the uid formerly? That's hard to understand.
Isn't that what the smbusers file is supposed to accomplish?

you do a "net getlocalsid" on the samba box, you will
probably get a different SID prefix than
You might want to
do a lookupname() (don't know the API call in win32) against
the samba box before choosing the SID to set in the sd.

How shall I know what UNIX user my Windows user is mapped to? If
smbusers contains a mapping like "foo = bar", and a UNIX user bar
doesn't exist, how should I ever find out that I have to ask for a UNIX
user foo? Sure, winbind seems to solve this problem, but that works

plus, if a UNIX user bar exists, I might try something completely
wrong in this scenario

only for domains, not for standalone machines.


Corinna

Jul 31 19:09, Volker Lendecke wrote:
Thu, Jul 31, 2008 at 10:35:46AM +0200, Corinna Vinschen wrote:
That's all. Apparently Samba knows to switch to the local UNIX user
corinna from the incoming request and creates the file as that user.
But eventually, in the call tyo set_nt_acl, legacy_sid_to_uid doesn't
know about the user mapping anymore and fails.

The problem very likely is that
is the SID of
user corinna on the workstation you're coming from, which
has nothing to do with the user corinna on the Samba box. If

Why not? The user with sid
has authenticated itself and is mapped by Samba to the user with uid 500.
Files are created as that user with uid 500. Why is that mapping not
transparent when creating files with security descriptors using the SID
which has been mapped to the uid formerly? That's hard to understand.
Isn't that what the smbusers file is supposed to accomplish?

you do a "net getlocalsid" on the samba box, you will
probably get a different SID prefix than
You might want to
do a lookupname() (don't know the API call in win32) against
the samba box before choosing the SID to set in the sd.

How shall I know what UNIX user my Windows user is mapped to? If
smbusers contains a mapping like "foo = bar", and a UNIX user bar
doesn't exist, how should I ever find out that I have to ask for a UNIX
user foo? Sure, winbind seems to solve this problem, but that works
only for domains, not for standalone machines.


Corinna

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.

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)

, here we go. That's what you would have to set in the sd.

How shall I know what UNIX user my Windows user is mapped to? If
smbusers contains a mapping like "foo = bar", and a UNIX user bar
doesn't exist, how should I ever find out that I have to ask for a UNIX
user foo? Sure, winbind seems to solve this problem, but that works
only for domains, not for standalone machines.

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?

Hmmm. Difficult. S-1-22-1-<uidshould 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.

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.

Maybe, but I'm rather wondering why the SID<->uid/sid mapping doesn't
work transparently from a Windows client PV 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.

BTW, it would be pretty much the same against a Windows file
server. The main difference is that you can set your local
box'es user SID in the sd, but it won't help you in *any*
way accessing that file.

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.

Volker

PGP SIGNATURE
Version: GnuPG v1.4.5 (GNU/Linux)


VB2okR1uEQ25y1ujW4n1U+c=
=ehn8
PGP SIGNATURE

test test

this is another damn test