Discussion:
Q: winbindd, unqualfied users, & name conflicts (a.k.a "Deathto 'winbind use default domain'!")
(too old to reply)
Dave Daugherty
2006-07-20 23:36:58 UTC
Permalink
My opinion:

Local users should always take precedence.

People should specifically refer to local users as
<SambaHostName>\localuser, if that is the form the SMB client insists on
sending.

Tacking on default domains and/or stripping domains to/from user names
and "trying them out" is playing fast and loose with user identity and
is a breeding ground for potential security holes.

Dave Daugherty


-----Original Message-----
From:
samba-technical-bounces+dave.daugherty=***@lists.samba.org
[mailto:samba-technical-bounces+dave.daugherty=***@lists.samba.
org] On Behalf Of simo
Sent: Thursday, July 20, 2006 9:59 AM
To: Gerald (Jerry) Carter
Cc: Volker Lendecke; ***@samba.org; samba-***@samba.org
Subject: Re: Q: winbindd, unqualfied users, & name conflicts (a.k.a
"Deathto 'winbind use default domain'!")
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Volker,
Assume I have a member server named LINUX joined to a
domain name AD. Now assume I have a local user named foo
in my passdb and a user named foo in the domain as well.
I'm modifying winbindd_util.c:parse_domain_user() to do
a lookup_name() to try to figure out which domain to prepend
to the username rather than just assuming its a domain user.
But this means that we'll always choose the local user
(due to the order of an isolated search in lookup_name()).
The main problem is the use default domain abomination
will confuse local and domain users of the same name and
possibly return incorrect group membership.
I am about a 1/2 inch from marking the smb.conf option
as deprecated and adding similar option to pam_winbind.conf.
This option just cannot work reliably.
Do you have any suggestions?
I would just document that local users will always take precendence.

Winbind use default domain is too valuable to be removed imho.

Simo.
--
Simo Sorce
Samba Team GPL Compliance Officer
email: ***@samba.org
http://samba.org
Gerald (Jerry) Carter
2006-07-20 23:52:46 UTC
Permalink
Post by Dave Daugherty
Local users should always take precedence.
People should specifically refer to local users as
<SambaHostName>\localuser, if that is the form the
SMB client insists on sending.
Tacking on default domains and/or stripping
domains to/from user names and "trying them out" is playing
fast and loose with user identity and
is a breeding ground for potential security holes.
Dave,

I don't think you fully understand the problem. We're
talking about Unix shell tools, not SMB clients. A local
username is always unqualfied when sent by Unix tools like
'id' to query group membership. A domain user may or may
not be qualfied so how do you know an unqualified domain
user from a normal local user? For example,

With 'winbind use default domain = no'

$ id
uid=780(jerry) gid=100(users)
groups=16(dialout),33(video),100(users),10001(BUILTIN\users),
10007(SUSE10\developers)

With 'winbind use default domain = yes'

$ id
uid=780(jerry) gid=100(users)
groups=16(dialout),33(video),100(users)

the problem is that when guesing the domain, we assume
the Windows domain name. Prior to querying group membership,
we do a lookup_name() query to the DC for this name
(DOMAIN\jerry) which fails since it is a local user.
So any local groups are excluded from the getgroups()
return.

*This* ambiguity is why I will be removing the geuss
work from the server code in 3.0.24.





cheers, jerry
=====================================================================
Samba ------- http://www.samba.org
Centeris ----------- http://www.centeris.com
"What man is a man who does not make the world better?" --Balian
Shlomi Yaakobovich
2006-07-22 08:53:44 UTC
Permalink
Hi,

We've recently ran into situations when the pwrite system call fails. I've noticed that on -1 return code, a "disk full" error is returned to the user. For example, in reply_write_and_X:

if (nwritten < (ssize_t)numtowrite) {
SCVAL(outbuf,smb_rcls,ERRHRD);
SSVAL(outbuf,smb_err,ERRdiskfull);
}

I saw no attempt to look at the exact errno, and attempt to return a more valid error code. Furthermore, perhaps it is worth while thinking of retrying the call (e.g. if errno is EINTR) instead of returning an error to the client ? We've noted that some applications don't behave well to "disk full" error, and abort their operations.
Another thing worth mentioning is that we are writing to an NFS mount.

Any input would be appreciated.
Thanks,
Shlomi
Shlomi Yaakobovich
2006-07-22 11:23:14 UTC
Permalink
Hi,

We've recently ran into situations when the pwrite system call fails. I've noticed that on -1 return code, a "disk full" error is returned to the user. For example, in reply_write_and_X:

if (nwritten < (ssize_t)numtowrite) {
SCVAL(outbuf,smb_rcls,ERRHRD);
SSVAL(outbuf,smb_err,ERRdiskfull);
}

I saw no attempt to look at the exact errno, and attempt to return a more valid error code. Furthermore, perhaps it is worth while thinking of retrying the call (e.g. if errno is EINTR) instead of returning an error to the client ? We've noted that some applications don't behave well to "disk full" error, and abort their operations.
Another thing worth mentioning is that we are writing to an NFS mount.

Any input would be appreciated.
Thanks,
Shlomi
Jeremy Allison
2006-07-22 20:48:22 UTC
Permalink
Post by Shlomi Yaakobovich
Hi,
Why does the pwrite system call fail ?
Post by Shlomi Yaakobovich
if (nwritten < (ssize_t)numtowrite) {
SCVAL(outbuf,smb_rcls,ERRHRD);
SSVAL(outbuf,smb_err,ERRdiskfull);
We should be more intelligent here, I'll look at it for
3.0.24.
Post by Shlomi Yaakobovich
I saw no attempt to look at the exact errno, and attempt to return a more valid error code. Furthermore, perhaps it is worth while thinking of retrying the call (e.g. if errno is EINTR) instead of returning an error to the client ? We've noted that some applications don't behave well to "disk full" error, and abort their operations.
You can't get EINTR on a write call on a disk system. Well you
can but only if you're writing to NFS on a soft mount, and that
breaks so many things it's not a good idea.
Post by Shlomi Yaakobovich
Another thing worth mentioning is that we are writing to an NFS mount.
Ah - I see. Soft mounts ?

Jeremy
Shlomi Yaakobovich
2006-07-22 22:48:17 UTC
Permalink
I still don't know what is the exact errno (current samba code does not have any relevant debug for this). My next step is to print this out, but the problem is quite rare. Copying a batch of 40GB of data (in several directories and files) increases the chances of reproducing it.

It might be a coincidence, but while this error happened, there was a suspicious kernel message in the log:
2006 Jul 21 21:59:57 node1 NOTICE: kernel: RPC: sendmsg returned error 105
2006 Jul 21 21:59:57 node1 WARNING: kernel: nfs: RPC call returned error 105

Oh, and our NFS mounts are hard...

I will attempt to reproduce, this time with some added information.

Thanks,
Shlomi

________________________________

From: Jeremy Allison [mailto:***@samba.org]
Sent: Sat 7/22/2006 6:47 PM
To: Shlomi Yaakobovich
Cc: samba-***@samba.org
Subject: Re: Write failures and proper error code return to clients
Post by Shlomi Yaakobovich
Hi,
Why does the pwrite system call fail ?
Post by Shlomi Yaakobovich
if (nwritten < (ssize_t)numtowrite) {
SCVAL(outbuf,smb_rcls,ERRHRD);
SSVAL(outbuf,smb_err,ERRdiskfull);
We should be more intelligent here, I'll look at it for
3.0.24.
Post by Shlomi Yaakobovich
I saw no attempt to look at the exact errno, and attempt to return a more valid error code. Furthermore, perhaps it is worth while thinking of retrying the call (e.g. if errno is EINTR) instead of returning an error to the client ? We've noted that some applications don't behave well to "disk full" error, and abort their operations.
You can't get EINTR on a write call on a disk system. Well you
can but only if you're writing to NFS on a soft mount, and that
breaks so many things it's not a good idea.
Post by Shlomi Yaakobovich
Another thing worth mentioning is that we are writing to an NFS mount.
Ah - I see. Soft mounts ?

Jeremy
Jeremy Allison
2006-07-22 23:07:20 UTC
Permalink
Post by Shlomi Yaakobovich
I still don't know what is the exact errno (current samba code does not have any relevant debug for this). My next step is to print this out, but the problem is quite rare. Copying a batch of 40GB of data (in several directories and files) increases the chances of reproducing it.
2006 Jul 21 21:59:57 node1 NOTICE: kernel: RPC: sendmsg returned error 105
2006 Jul 21 21:59:57 node1 WARNING: kernel: nfs: RPC call returned error 105
That's probably returning as an EIO then. It's just going to be
returned as a write fault. Out of space is wrong, but the client
is still going to fail in this case.
Post by Shlomi Yaakobovich
Oh, and our NFS mounts are hard...
NFS client bug then.

Jeremy.
Jeremy Allison
2006-07-25 04:42:49 UTC
Permalink
Post by Shlomi Yaakobovich
Hi,
if (nwritten < (ssize_t)numtowrite) {
SCVAL(outbuf,smb_rcls,ERRHRD);
SSVAL(outbuf,smb_err,ERRdiskfull);
}
I saw no attempt to look at the exact errno, and attempt to return a more valid error code.
Ok, I've now had time to look at this.
You missed this code in reply_write_and_X() :

if(((nwritten == 0) && (numtowrite != 0))||(nwritten < 0)) {
END_PROFILE(SMBwriteX);
return(UNIXERROR(ERRHRD,ERRdiskfull));
}

UNIXERROR looks at errno. What is errno set to in your
particular case ? The default of ERRdiskfull is only
returned if errno == 0.

The code you complain about is a fallback case just in case
there are some systems where write returns less than was
requested on ENOSPC. It should never be true on a working POSIX
system.
Post by Shlomi Yaakobovich
Furthermore, perhaps it is worth while thinking of retrying the call (e.g. if errno is EINTR) instead of returning an error to the client ? We've noted that some applications don't behave well to "disk full" error, and abort their operations.
As noted before, this can't happen on disk writes except
for soft mounts.

Jeremy.
Shlomi Yaakobovich
2006-07-25 11:07:29 UTC
Permalink
Hi,
Post by Jeremy Allison
Ok, I've now had time to look at this.
if(((nwritten == 0) && (numtowrite != 0))||(nwritten < 0)) {
END_PROFILE(SMBwriteX);
return(UNIXERROR(ERRHRD,ERRdiskfull));
}
This actually should be:

if(((nwritten == 0) && (numtowrite != 0))||(nwritten < 0)) {
END_PROFILE(SMBwriteX);
if (errno == EDQUOT) {
return ERROR_NT(NT_STATUS_QUOTA_EXCEEDED);
}
return(UNIXERROR(ERRHRD,ERRdiskfull));
}

The reason is that a windows client 2003 and down, for both errors (disk full and quota exceeded) the error message will be "There is not enough space on the disk". Only for XP client a user will get different error message: "Not enough quota is available to process this command", which is the right one in case of a quota error. Dina Fine found this out and added the above fix. BTW, I think this is relevant to all types of writes, not just the specific case we've mentioned here. E.g I saw your latest checkin (17220) in reply.c, I believe this is the same there as well.

Regarding the quota change, perhaps it will be better to change it in error.c, e.g. like this (in errormap.c):

#ifdef EDQUOT
{ EDQUOT, ERRHRD, ERRdiskfull, NT_STATUS_QUOTA_EXCEEDED},
#endif
Post by Jeremy Allison
UNIXERROR looks at errno. What is errno set to in your
particular case ? The default of ERRdiskfull is only
returned if errno == 0.
It also returns ERRdiskfull if it does not find the exact errno in the unix_dos_nt_errmap array. This was the case here, the errno was 105 (ENOBUFS - No buffer space available). This might be related to the kernel/NFS client, but samba currently is unaware of this error code. I'm not sure it should be though, it clearly indicates a problem. In our case the problem was transient, a second retry (when encountering this error) was successful.

Anyways, I'm still not sure what caused the ENOBUFS error, maybe it is indeed only when writing to NFS mounts. In the meantime, since we needed to apply a quick fix, we just added 2 more retries, which apparently made our problem disappear (not get solved...).

Thanks,
Shlomi
Jeremy Allison
2006-07-25 21:27:18 UTC
Permalink
Post by Jeremy Allison
if(((nwritten == 0) && (numtowrite != 0))||(nwritten < 0)) {
END_PROFILE(SMBwriteX);
if (errno == EDQUOT) {
return ERROR_NT(NT_STATUS_QUOTA_EXCEEDED);
}
return(UNIXERROR(ERRHRD,ERRdiskfull));
}
Good catch !
Post by Jeremy Allison
The reason is that a windows client 2003 and down, for both errors (disk full and quota exceeded) the error message will be "There is not enough space on the disk". Only for XP client a user will get different error message: "Not enough quota is available to process this command", which is the right one in case of a quota error. Dina Fine found this out and added the above fix. BTW, I think this is relevant to all types of writes, not just the specific case we've mentioned here. E.g I saw your latest checkin (17220) in reply.c, I believe this is the same there as well.
#ifdef EDQUOT
{ EDQUOT, ERRHRD, ERRdiskfull, NT_STATUS_QUOTA_EXCEEDED},
#endif
Indeed - fixing it in the error mapping is the correct
solution. I'll do that asap.
Post by Jeremy Allison
It also returns ERRdiskfull if it does not find the exact errno in the unix_dos_nt_errmap array. This was the case here, the errno was 105 (ENOBUFS - No buffer space available). This might be related to the kernel/NFS client, but samba currently is unaware of this error code. I'm not sure it should be though, it clearly indicates a problem. In our case the problem was transient, a second retry (when encountering this error) was successful.
Anyways, I'm still not sure what caused the ENOBUFS error, maybe it is indeed only when writing to NFS mounts. In the meantime, since we needed to apply a quick fix, we just added 2 more retries, which apparently made our problem disappear (not get solved...).
Ah - ENOBUFS is a new errno return for write only covered
in the Single UNIX specification version 3. I'll update
the error map to cover the possible errno vals.

Jeremy.

Continue reading on narkive:
Loading...