Re: Problems with ACLs in 2.2.8

2003-04-01 Thread Michael Steffens
Hello Buck,

Buck Huppmann wrote:
i'm also seeing some aberrant ACL-setting behavior in samba 2.2.8. more-
over, the new Creator Owner and Creator Group semantics are bewildering,
although i can understand if, in that sense, they're just mimicking NT
behavior all the more closely. at any rate, below's a patch that purports
to do the following:
1. the hunk for util_sid.c make the Creator Owner and Creator Group
   icons show up appropriately in my NT-permissions-chooser thingy
2. the first three hunks for posix_acls.c allows one to drop entries from
   an ACL without having samba re-insert the ``missing'' ACEs behind the
   scenes with the share-default perms. this may or may not address your
   concern
From my understanding Samba has no other choice than inserting missing
object ACEs, because it's impossible to set a POSIX ACL without. The
crucial point not being whether, but what to insert. What does the
client intend when sending an ACL without object entries?
The purpose of the modification in the new ACL code was to cope with
W2k clients attempting to copy ACL from one file to another, as office
apps are doing when storing into temporary files. Without preserving
existing object ACEs the user who has just stored ends up without
write permissions, if write access to the original file was only
via a supplementary group.
3. the fourth hunk excepts Creator Owner and Creator Group from being
   dropped from the incoming ACL as ``non-mappable SIDs''
I'm not sure what it actually implies, but sounds promising. Hoping that
this modication could get our missing ACEs preserved (i.e. assuming they do
get transmitted but were filtered out) I tried your modifications from
2. and 3.
Bad luck. Still breaks W2k clients copying ACLs to temp files.

How do we want to cope with it?

Cheers!
Michael


4. the fifth hunk corrects for the fact that--according to the ``-s''
   option description from the setfacl(1) man page of Solaris 2.6, anyway--
   Solaris needs a default ``CLASS_OBJ'' entry if it has any other default
   ACL entries
5. the sixth hunk makes use of the mask_perms mode that set_canon_ace_list()
   munges all the way through but then does nothing with. this isn't required
   for correct functionality, though, i don't think
   
6. the seventh hunk (in NT4-compatible mode) abridges the code to elide
   the non-default ACL entry for the group owner if the group owner has no
   permissions, since i thought this might allay confusion, as indicated by
   the CPP macro name used there. again, this isn't required for correct
   functionality

none of these are meant to be applied to anybody's samba source tree; i'm
just trying to point out some areas that may need attention
i think, however, for my purposes, i'm just going to drop in the old 2.2.7
posix_acls.c, since i find named ACEs with non-bogus perms in both parenthe-
sized slots in the NT-permissions-thingy display much less confusing, if a
bit misleading
--buck

On Tue, Mar 25, 2003 at 01:39:22AM +, Jan Houstek wrote:

Hi all!

I posted this in [EMAIL PROTECTED] but there were no reactions.
Particulary I'm interested if anyone observe the same behavior.
-- Honza Houstek

--

server:
linux 2.4.19 with xfs 1.2 and its ACL
libacl 2.0.19
samba 2.2.8 compiled from source with --with-acl-support
acting as PDC
interesting parts of smb.conf
create mask = 0600
directory mask = 0700
[testshare]
path = /data/testshare
readonly = No
client:
1) Windows XP, servicepack 1.2a
2) smbmount from another linux box
server:~# getfacl /data/testshare/testdir
# file: testdir
# owner: testuser
# group: users
user::rwx
group::---
group:somegroup:r-x
group:anothergroup:rwx
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:somegroup:r-x
default:group:anothergroup:rwx
default:mask::rwx
default:other::---
server:~# umask 007
server:~# mkdir /data/testshare/testdir/test1
server:~# getfacl /data/testshare/testdir/test1
# file: test1
# owner: root
# group: root
user::rwx
group::---
group:somegroup:r-x
group:anothergroup:rwx
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:somegroup:r-x
default:group:anothergroup:rwx
default:mask::rwx
default:other::---
On windows:
logon to domain as testuser
create test2 in testdir (right mouse button - New - Folder)
server:~# getfacl /data/testshare/testdir/test2
# file: test2
# owner: testuser
# group: users
user::rwx
group::rwx  # !!! problem !!!
group:somegroup:r-x
group:anothergroup:rwx
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:somegroup:r-x
default:group:anothergroup:rwx
default:mask::rwx
default:other::---


--- samba-2.2.8/source/lib/util_sid.c.orig	Fri Mar 14 16:34:47 2003
+++ samba-2.2.8/source/lib/util_sid.c	Mon Mar 31 

SID related debug messages

2003-03-31 Thread Michael Steffens
Hi,

the attached enhancements of SID related debug messages were quite
useful for me for tracking down where strange SIDs winbindd
complained about are coming from.
Being there I found that my suspicous SIDs are included in the
user token from DC on domain client validation, in the other
sids section. Is this the place where W2k SID history lives?
Cheers!
Michael
Index: source/nsswitch/winbindd_group.c
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd_group.c,v
retrieving revision 1.3.4.25
diff -u -r1.3.4.25 winbindd_group.c
--- source/nsswitch/winbindd_group.c14 Oct 2002 03:00:14 -  1.3.4.25
+++ source/nsswitch/winbindd_group.c31 Mar 2003 11:46:32 -
@@ -290,7 +290,10 @@
sid_append_rid(group_sid, group_rid);
 
if (!winbindd_lookup_name_by_sid(group_sid, dom_name, group_name, 
name_type)) {
-   DEBUG(1, (could not lookup sid\n));
+   fstring temp;
+
+   sid_to_string(temp, group_sid);
+   DEBUG(1, (could not lookup sid %s\n, temp));
return WINBINDD_ERROR;
}
 
Index: source/nsswitch/winbindd_util.c
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd_util.c,v
retrieving revision 1.7.4.26
diff -u -r1.7.4.26 winbindd_util.c
--- source/nsswitch/winbindd_util.c 4 Mar 2003 23:35:50 -   1.7.4.26
+++ source/nsswitch/winbindd_util.c 31 Mar 2003 11:46:32 -
@@ -262,7 +262,7 @@
domain = find_domain_from_sid(sid);
 
if (!domain) {
-   DEBUG(1,(Can't find domain from sid\n));
+   DEBUG(1,(Can't find domain from sid %s\n, sid_string_static(sid)));
return False;
}
 
Index: source/smbd/password.c
===
RCS file: /cvsroot/samba/source/smbd/password.c,v
retrieving revision 1.186.2.71
diff -u -r1.186.2.71 password.c
--- source/smbd/password.c  4 Mar 2003 23:36:00 -   1.186.2.71
+++ source/smbd/password.c  31 Mar 2003 11:46:32 -
@@ -1667,6 +1667,16 @@
sid_append_rid(ptok-user_sids[i], info3.gids[i].g_rid);
}
 
+   if (DEBUGLVL(10)) {
+   dbgtext(info3 group sids for %s in domain %s\n, user, 
domain);
+   for (i = 0; i  info3.num_groups2; i++) {
+   fstring temp;
+
+   sid_to_string(temp, ptok-user_sids[i]);
+   dbgtext([%d] %s\n, i, temp);
+   }
+   }
+
/* Universal group memberships for other domains are
   stored in the info3.other_sids field.  We also need to
   do sid filtering here. */
@@ -1674,6 +1684,16 @@
for (i = 0; i  info3.num_other_sids; i++)
sid_copy(ptok-user_sids[info3.num_groups2 + i], 
 info3.other_sids[i].sid);
+
+   if (DEBUGLVL(10)) {
+   dbgtext(info3 other sids for %s in domain %s\n, user, 
domain);
+   for (i = 0; i  info3.num_other_sids; i++) {
+   fstring temp;
+
+   sid_to_string(temp, ptok-user_sids[info3.num_groups2 
+ i]);
+   dbgtext([%d] %s\n, i, temp);
+   }
+   }
 
*pptoken = ptok;
}


Re: Problems with ACLs in 2.2.8

2003-03-25 Thread Michael Steffens
Jan Houstek wrote:
server:
linux 2.4.19 with xfs 1.2 and its ACL
libacl 2.0.19
samba 2.2.8 compiled from source with --with-acl-support
acting as PDC
interesting parts of smb.conf
create mask = 0600
directory mask = 0700
[testshare]
path = /data/testshare
readonly = No
client:
1) Windows XP, servicepack 1.2a
2) smbmount from another linux box
server:~# getfacl /data/testshare/testdir
# file: testdir
# owner: testuser
# group: users
user::rwx
group::---
group:somegroup:r-x
group:anothergroup:rwx
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:somegroup:r-x
default:group:anothergroup:rwx
default:mask::rwx
default:other::---
server:~# umask 007
server:~# mkdir /data/testshare/testdir/test1
server:~# getfacl /data/testshare/testdir/test1
# file: test1
# owner: root
# group: root
user::rwx
group::---
group:somegroup:r-x
group:anothergroup:rwx
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:somegroup:r-x
default:group:anothergroup:rwx
default:mask::rwx
default:other::---
On windows:
logon to domain as testuser
create test2 in testdir (right mouse button - New - Folder)
server:~# getfacl /data/testshare/testdir/test2
# file: test2
# owner: testuser
# group: users
user::rwx
group::rwx  # !!! problem !!!
group:somegroup:r-x
group:anothergroup:rwx
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:somegroup:r-x
default:group:anothergroup:rwx
default:mask::rwx
default:other::---
I could (almost) reproduce it on HP-UX, and (almost) fix it
using inherit acls = Yes. :)
Both almost refer to mask (or class, respectively) behaving
a bit strange. But this might be platform specific.
Maybe using inherit acls could already do the job in your
setup?
Cheers!
Michael



Re: Problems with ACLs in 2.2.8

2003-03-25 Thread Michael Steffens
Hello Jeff,

Jeff Mandel wrote:
As long as you're having a look, will you give a look at the mode 
problem at file create time? In some cases samba over-rides the umask 
and inherited acls and creates the file as r--r--r--. Only samba's force 
create will kind of fix that. It's like the --with-acl-support is not 
always working.
Does that happen with 2.2.8? Some of the changes to Samba's ACL
code were meant to avoid exactly this problem.
In case it happens with 2.2.8, some details about the conditions
under which it happens could be helpful.
Cheers!
Michael


Proposal for smbd failing more gracefully when ngroups NGROUPS_MAX

2003-03-17 Thread Michael Steffens
Hello,

The [Samba] number of groups of NT account causes authentication
problems thread discussed the problem of dealing with NT users,
which are members of more domain global groups than the OS running
Samba can cope with.
Limits do vary, some have 16, or 20, or 32, with some platforms it's
tunable, with others it isn't, or only with very much trouble.
How about making smbd a bit more tolerant concerning groups? If the
total number returned by winbind for a given user exceeds maximum,
it may drop all but the primary group.
This would at least allow to cope with such users in setups where
access control is only done via valid users, plus force group
for common access.
Users who got their supplementary groups stripped this way would not
be able to utilize their memberships when using ACLs. This should
represent a fail-to-close, except when others is having more
privileges than specific groups.
Would this be acceptable? It's is not ideal, of course, but maybe
better than no way of dealing with such users?
Attached is a little patch implementing this in 2.2.8.

Cheers!
Michael


Index: source/nsswitch/wb_client.c
===
RCS file: /cvsroot/samba/source/nsswitch/wb_client.c,v
retrieving revision 1.5.2.19
diff -u -r1.5.2.19 wb_client.c
--- source/nsswitch/wb_client.c 13 Sep 2002 23:46:27 -  1.5.2.19
+++ source/nsswitch/wb_client.c 17 Mar 2003 14:11:29 -
@@ -325,6 +325,15 @@
ngroups++;
}
 
+   /* Omit supplementary groups when exceeding maximum */
+
+   if (ngroups  groups_max()) {
+   DEBUG(1,(number of group memberships (%d) for user %s exceeds 
maximum %d, restricting to gid %d\n,
+   ngroups, user, groups_max(), gid));
+   groups[0] = gid;
+   ngroups = 1;
+   }
+
/* Set the groups */
 
if (sys_setgroups(ngroups, groups) == -1) {
Index: source/smbd/sec_ctx.c
===
RCS file: /cvsroot/samba/source/smbd/sec_ctx.c,v
retrieving revision 1.7.2.19
diff -u -r1.7.2.19 sec_ctx.c
--- source/smbd/sec_ctx.c   16 Jul 2002 01:09:44 -  1.7.2.19
+++ source/smbd/sec_ctx.c   17 Mar 2003 14:11:29 -
@@ -343,7 +343,7 @@
gain_root();
 
 #ifdef HAVE_SETGROUPS
-   sys_setgroups(ngroups, groups);
+   sys_setgroups((ngroups  groups_max() ? 0 : ngroups), groups);
 #endif
 
ctx_p-ngroups = ngroups;
@@ -419,7 +419,7 @@
prev_ctx_p = sec_ctx_stack[sec_ctx_stack_ndx];
 
 #ifdef HAVE_SETGROUPS
-   sys_setgroups(prev_ctx_p-ngroups, prev_ctx_p-groups);
+   sys_setgroups((prev_ctx_p-ngroups  groups_max() ? 0 : prev_ctx_p-ngroups), 
prev_ctx_p-groups);
 #endif
 
become_id(prev_ctx_p-uid, prev_ctx_p-gid);


Re: Showstopper! Samba 2.2.8 can't read TDB files from previousversions.

2003-03-16 Thread Michael Steffens
Fredrik Ohrn wrote:
It seems that Samba 2.2.8 is unable to open TDB files written by older 
versions. Instead it just overwrites them with a fresh file.

This caused our domain-server to loose the domain SID leaving all our NT 
clients out in the cold. We use a domain SID extracted from the previous 
PDC, an old WinNT 4.0 server that was scrapped.

Our print server also lost it's registry of printerdrivers and settings.

To verify this yourself, try the tdbtool utility. The 2.2.8 version can't 
open old TDB files. The other way round works though, tdbtool from 
2.2.7a can open new TDB files written by 2.2.8.

To salvage the domain SID I copied smbpasswd.c from 2.2.8 into a 2.2.7a 
source tree and compiled it, then I could use the new -X and -W options to 
extract the SID from the old secrets.tdb and write it into a fresh TDB 
from 2.2.8.

I'm still working on the printersettings...

Anyway, if anyone can replicate this I'd suggest that 2.2.8 should be 
retracted or atleast a big fat warning should be posted that you may 
loose your domain SID effectively killing your domain-controller.
Hmm, at least secrets.tdb and winbind_idmap.tdb survived the upgrade
well on four machines here, previous versions 2.2.7a and 2.2.6. All
of them running as domain members, however, none being DC...
Cheers!
Michael


Re: New approach for winbind to match Windows to UNIX users and back

2003-03-13 Thread Michael Steffens
Hi Michael,

Michael Fair wrote:
The admin would have to rechown all the files from the
old ids to the new ones, but a simple find command could
probably manage that.
How does that work?  Any major wrinkles?
I'm not feeling really comfortable with winbind assigning all
UIDs and GIDs on a system, as it does need to coexist with other
means and tools for Unix user management.
Reassigning their IDs is a major pain, and often impossible.

If winbind could only be used when taking over ID management
entirely, we would be in trouble. So this behaviour needs to
be at least optional...
Cheers!
Michael




Re: New approach for winbind to match Windows to UNIX users and back

2003-03-13 Thread Michael Steffens
Hi Michael,

Michael Fair wrote:
Oh yes, entirely!  Nothing I mentioned was an attempt
to put winbind in control of all the UID/GIDs on a system.
I personally have never used, nor even heard of a system
that used UID/GIDs 100,000,000 and above.   That's the address
space that winbind would be using.  Everything below that
0 through 99,999,999 would be reserved for the normal system
(as I mentioned earlier in the post).  But just because I
haven't encountered doesn't mean it doesn't exist which was
my primary concern (if the address space is in use, then
it is not a solution and we'll need to come up with
something else).
Hmmpf, sorry, sometimes I need to be told things twice
to understand :)
Got it!
Michael


Re: [PATCH] fix sid_to_uid() return correct sidtype

2003-02-20 Thread Michael Steffens
[EMAIL PROTECTED] wrote:

On Wed, Feb 19, 2003 at 10:20:35PM +0100, Stefan (metze) Metzmacher wrote:


At 21:07 19.02.2003 +, [EMAIL PROTECTED] wrote:


On Wed, Feb 19, 2003 at 10:03:57PM +0100, Stefan (metze) Metzmacher wrote:


HI all,

here's a small fix for returning the correct sidtype in sid_to_uid() and
sid_to_gid()

this should be applied to all branches with the new uid - sid caching 

code

No attachment - please try again.

Jeremy.


mailman filtered it out...:-(



Actually I made the cache cache the sidtype also.
Please check over the code I just checked in...


Had also thought about caching the sitype, but then omitted it. Isn't
it redundant? What else than SID_NAME_USER and SID_NAME_DOM_GRP can
go there, residing in different caches?

Cheers!
Michael




Re: [PATCH] fix sid_to_uid() return correct sidtype

2003-02-20 Thread Michael Steffens
Michael Steffens wrote:

[EMAIL PROTECTED] wrote:


On Wed, Feb 19, 2003 at 10:20:35PM +0100, Stefan (metze) Metzmacher 
wrote:

At 21:07 19.02.2003 +, [EMAIL PROTECTED] wrote:


On Wed, Feb 19, 2003 at 10:03:57PM +0100, Stefan (metze) Metzmacher 
wrote:

HI all,

here's a small fix for returning the correct sidtype in 
sid_to_uid() and
sid_to_gid()

this should be applied to all branches with the new uid - sid 
caching 


code

No attachment - please try again.

Jeremy.



mailman filtered it out...:-(




Actually I made the cache cache the sidtype also.
Please check over the code I just checked in...



Had also thought about caching the sitype, but then omitted it. Isn't
it redundant? What else than SID_NAME_USER and SID_NAME_DOM_GRP can
go there, residing in different caches?


Noticed why :)
The current caching code does also cache local lookups, meaning that
local groups (and machine SIDs when Samba is running as DC) can also
occur?

Hmm, I'm not sure whether the speed gain for local lookups outweighs
the costs of having them wipe winbind SID mapping cache entries.
The latter ones look more expensive to me.

Cheers!
Michael







Re: [PATCH] fix sid_to_uid() return correct sidtype

2003-02-20 Thread Michael Steffens
Hi Jeremy,

[EMAIL PROTECTED] wrote:

On Thu, Feb 20, 2003 at 01:20:14PM +0100, Michael Steffens wrote:

Hmm, I'm not sure whether the speed gain for local lookups outweighs
the costs of having them wipe winbind SID mapping cache entries.
The latter ones look more expensive to me.



Hmmm. True, but the local lookups could be going via NIS or another
method to a remote server.


Had not taken NIS into account. Good point.


I also reduced the cache size to 10.


Actually 100 :)


Can
you test the code in you environment and see if it still gives the
speedup you noticed.


I did on a test machine, already during the testing of
W2k and XP office apps use of ACLs. Caching did fine.
(ACLs did not.) I don't expect the cache behaviour to
be much different on the production box. Both don't have
NIS, do not act as DCs, and share user management is
almost pure winbind driven. (I'm a little winbind biased :)


If not I'll remove the local caching code.


I was wrong and you convinced me!

Thanks!
Michael








Re: Locking db getting corrupt?

2003-02-20 Thread Michael Steffens
Ray Frush wrote:

We've been seeing a re-curring problem on one of our Samba servers:
Samba 2.2.7 running on HP-UX 11.0.

After a week of running relatively quietly, we'll get a rash of errors 
in smbd.log associated with a call from a user that their connection is 
getting dropped. 
 I_ve been dropped off twice in
the past couple of days. So far I_ve been able to
get back on -- once took a reboot of my pc, this
time it only took trying to reconnect several
times.

[...]

[2003/02/19 12:45:24, 0] locking/brlock.c:(235)
 Failed to open byte range locking database
[2003/02/19 12:45:24, 0] locking/locking.c:(328)
 ERROR: Failed to initialise locking database
[2003/02/19 12:45:24, 0] locking/brlock.c:(235)
 Failed to open byte range locking database
[2003/02/19 12:45:24, 0] locking/locking.c:(328)
 ERROR: Failed to initialise locking database


We haven't had these since running 2.2.7a for about three weeks
now on HP-UX 11.11. But messages do remind those smbstatus does
report when the locking database just doesn't exist, yet.
So it might be temporarily unaccessible?

Does dmesg report anything suspicous, like it has
run out of nfiles or nflocks? In that case these kernel
parameters would need to be increased.

Michael




Patch: (Problem with nt acl support when saving Excel or WordFiles)

2003-02-17 Thread Michael Steffens
Hi all,

tried to dig into it, testing with various clients, browsing level 10 logs
and hacking posic_acls.c, which are all almost equally trivial (read: oh
dear it got my head spinning. :).

I think there are basically two problem:

 1. Windows clients do not always send ACEs for SMB_ACL_USER_OBJ, SMB_ACL_GROUP_OBJ,
and SMB_ACL_OTHER.
The function ensure_canon_entry_valid() is prepared for that, but tries
to guess values from group or other permissions, respectively, otherwise
falling back to minimum r-- for the owner. Even if the owner had full
permissions before setting ACL. This is the problem with W2k clients.

 2. Function set_nt_acl() always chowns *before* attempting to set POSIX ACLs.
This is ok in a take-ownership situation, but must fail if the file is
to be given away. This is the problem with XP clients, trying to transfer
ownership of the original file to the temp file.

The problem with NT4 clients (no ACEs are transferred to the temp file, thus
are lost after moving the temp file to the original name) is a client problem.
It simply doesn't attempt to.

I have played around with that using posic_acls.c from 3.0 merged into 2.2.
As a result I can now present two patches, one for each branch. They
basically modify:

 1. Interpret missing SMB_ACL_USER_OBJ, SMB_ACL_GROUP_OBJ, or SMB_ACL_OTHER
as preserve current value instead of attempting to build one ourself.
The original code is still in, but only as fallback in case current values
can't be retrieved.

 2. Rearrange set_nt_acl() such that chown is only done before setting
ACLs if there is either no change of owning user, or change of owning
user is towards the current user. Otherwise chown is done after setting
ACLs.

It now seems to produce reasonable results. (Well, as far as it can. If
NT4 doesn't even try to transfer ACEs, only deliberate use of named default
ACEs and/or force group or the crystal ball can help :)

I have tested this with HP-UX, but it shouldn't be platform dependent.
Maybe someone could try on a different platform?

Cheers!
Michael


Index: source/smbd/posix_acls.c
===
RCS file: /cvsroot/samba/source/smbd/posix_acls.c,v
retrieving revision 1.1.4.67
diff -u -r1.1.4.67 posix_acls.c
--- source/smbd/posix_acls.c8 Oct 2002 00:19:43 -   1.1.4.67
+++ source/smbd/posix_acls.c17 Feb 2003 09:47:51 -
@@ -1,8 +1,8 @@
 /*
-   Unix SMB/Netbios implementation.
-   Version 1.9.
+   Unix SMB/CIFS implementation.
SMB NT Security Descriptor / Unix permission conversion.
-   Copyright (C) Jeremy Allison 1994-2000
+   Copyright (C) Jeremy Allison 1994-2000.
+   Copyright (C) Andreas Gruenbacher 2002.
 
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -105,7 +105,7 @@
dbgtext( canon_ace index %d. Type = %s , num, pace-attr == ALLOW_ACE ? 
allow : deny );
dbgtext( SID = %s , sid_to_string( str, pace-trustee));
if (pace-owner_type == UID_ACE) {
-   char *u_name = uidtoname(pace-unix_ug.uid);
+   const char *u_name = uidtoname(pace-unix_ug.uid);
dbgtext( uid %u (%s) , (unsigned int)pace-unix_ug.uid, u_name);
} else if (pace-owner_type == GID_ACE) {
char *g_name = gidtoname(pace-unix_ug.gid);
@@ -331,6 +331,32 @@
 }
 
 /
+ Check if we need to return NT4.x compatible ACL entries.
+/
+
+static BOOL nt4_compatible_acls(void)
+{
+   /*
+* Should be
+*
+*   const char *compat = lp_acl_compatibility(); 
+*
+* but we don't have this parameter in 2.2, yet.  Always
+* adapt to client.
+*/
+   const char *compat = ;
+
+   if (*compat == '\0') {
+   enum remote_arch_types ra_type = get_remote_arch();
+
+   /* Automatically adapt to client */
+   return (ra_type = RA_WINNT);
+   } else
+   return (strequal(compat, winnt));
+}
+
+
+/
  Map canon_ace perms to permission bits NT.
  The attr element is not used here - we only process deny entries on set,
  not get. Deny entries are implicit on get with ace-perms = 0.
@@ -346,7 +372,19 @@
if ((ace-perms  ALL_ACE_PERMS) == ALL_ACE_PERMS) {
nt_mask = UNIX_ACCESS_RWX;
} else if ((ace-perms  ALL_ACE_PERMS) == (mode_t)0) {
-   nt_mask = UNIX_ACCESS_NONE;
+   /*
+* Windows NT refuses to display ACEs with no permissions in them (but
+* they are perfectly legal with Windows 2000). If the ACE has empty
+* permissions we cannot use 0, so we use 

Re: Winbindd limited by select

2003-02-15 Thread Michael Steffens
Michael Steffens wrote:

Ken Cross wrote:


There is pretty much a one-to-one correspondence between the number of
smbd processes open (i.e. connected users) and winbindd file descriptors
(per fstat).



Hmm, it may be platform specific. smbd connects winbindd both directly
and via NSS. On HP-UX it consumes two client pipes per smbd, and this
might be due to linking libnss_winbind.1 with -B symbolic, having
symbols resolved locally, such that the two ways used by every smbd
don't share client environment? It's just a guess.


It seems correct, the behaviour is depending on how the NSS backend
library was linked. Build libnss_winbind.1 without the linker option
-B symbolic and, bingo, there is only one client connection per smbd.

For the PAM module libpam_winbind.1 preferred local resolution of
symbols with -B symbolic is still required to work properly. So
optimally the two backend libraries should be linked differently.

Cheers!
Michael





Re: Winbindd limited by select

2003-02-15 Thread Michael Steffens
David Collier-Brown -- Customer Engineering wrote:

Ken Cross wrote:


#define FD_SETSIZE 2048  /* Max # of winbindd connections */

must occur before the first invocation of sys/types.

This could be a build option, but it might be much simpler to hard-code
it in local.h, which is what I did to fix it.

Can somebody check the implications of this on Solaris, HPUX, etc.?


 
	On Solaris, compiled as a 32-bit app, the limit
	applies.  Compiled as a 64-bit app, you can have 
	as many FDs as you want.

	However, there is currently no good reason to build
	Samba as a 64-bit app: it doesn't need a bigger
	address space.

I'm wondering, basically concerning all platforms, whether this
is about the size of fd_set, or about the number of FDs the
kernel will actually assign to a process.

If the latter one is not limited, wouldn't a single excessive FD
consumer impact other processes?

Cheers!
Michael




Re: Winbindd limited by select

2003-02-15 Thread Michael Steffens
Ken Cross wrote:

My $0.02...


Mike Sweet wrote:


Sooo, my recommendations are as follows:

   1. Provide a configure option (--with-maxfiles or similar)
  to configure the upper limit you want to support in SAMBA.
   2. Provide a smb.conf option to control the max number of
  file descriptors.



There's currently a max smbd processes in 3.0.  Would that suffice for
max number of fd's for winbindd?


I don't think so. It's not desireable to restrict the number
of smbds to the number of FDs that winbindd can have
simultanously, IMHO.

Michael




Re: Winbindd limited by select

2003-02-15 Thread Michael Steffens
Ken Cross wrote:

I was suggesting the other way around -- the number of winbindd fd's
shouldn't be more than the max # of smbd's (well, maybe a *few* more).


But if you are having a system hard limit of 1024 FDs per process,
for example, which you can't raise via setrlimit, you could only
configure less than that number of smbds.

Coupling these numbers does not make sense IMHO for another reason:
Every process can become a winbind client, even without knowing
about winbind or Samba, via NSS and PAM. How to take these into
account?

I think winbindd shutting down idle connections (not immediately,
there may further requests come along quickly, and never if
a connection carries a getpwent/getgrent status) is less trouble.

Cheers!
Michael




Re: Problem with nt acl support when saving Excel or Word Files

2003-02-12 Thread Michael Steffens
Michael Steffens wrote:

On the other hand, in debug level 10, create_canon_ace_lists() always logs
that clients attempt to apply the corresponding allow ACEs. This part does
work correctly for W2k clients, however.


Should probably add, that I can only pretend reading level 10 logs. :)

It's rather peeking around whether something looks remotely familiar,
and most probably (for sure) I have missed the relevant parts...




Does 3.0 have the same problem? (Re: Problem with nt acl supportwhen saving Excel or Word Files)

2003-02-12 Thread Michael Steffens
What I would be very curious about: Does 3.0 exhibit the same problem?

 http://lists.samba.org/pipermail/samba-technical/2003-January/041748.html
 http://lists.samba.org/pipermail/samba-technical/2003-February/042392.html

Maybe someone already running 3.0 could try?

Cheers!
Michael





Re: Winbindd limited by select

2003-02-12 Thread Michael Steffens
Hi Ken,

Ken Cross wrote:

I've run into a problem with winbindd in both 2.2.x and 3.0 where it
just locks up after a while on large, busy networks.

We finally tracked down the problem to the fact that the C library
select function is limited by default to 256 file descriptors in
NetBSD (1024 in FreeBSD, 2048 in Linux).  So once 256 (or whatever) smbd
processes connected to winbindd, it broke pretty badly and was very hard
to kill.

This is set at compile-time, not run-time.  This line:

 #define FD_SETSIZE 2048  /* Max # of winbindd connections */

must occur before the first invocation of sys/types.

This could be a build option, but it might be much simpler to hard-code
it in local.h, which is what I did to fix it.

Can somebody check the implications of this on Solaris, HPUX, etc.?


This will hardly do on HP-UX, because there is a kernel parameter
maxfiles controlling the per-process max number of filedescriptors.

It's 60 by default after installation, but is tunable (with reboot).
I would not recommend to set it too high, since it's also a fuse against
single user processes eating up all available file descriptors (controlled
by nfiles).

We have hit the limit *very* quickly on our Winbind production box,
of course, and I have increased maxfiles to 300. Still quite low
when expecting a couple of hundret smbd to become winbind clients.
Each of them consuming two FDs.

The solution (and this should also work on other platforms) was to
have winbindd housekeep its client connections by shutting down
idle connections, and have clients reconnect when required:

  http://lists.samba.org/pipermail/samba-technical/2003-February/042210.html

The threshold was chosen to be 100 active connections, which keeps
winbindd well below 300 FDs. Below 140, actually, including network
sockets and open database and log files.

This only works out well if clients don't connect too frequently,
however, and

  http://lists.samba.org/pipermail/samba-technical/2003-February/042170.html

helped achieving this.

I'm tracking winbindd shutting down sockets for about a week now,
and have extended the DEBUG line in remove_idle_client() to also print
idle time of removal candidates.

With about 100 concurrent smbds (i.e. ~200 client pipes) it
almost always finds connections idle for more than an hour.
I would assume forcing these to reconnect should have no measurable
impact, and the solution should scale to a multitude of its
current load.

It can't be applied directly to 3.0, however. I'm assuming that identifying
idle connections is more complicated there, as both read and write buffers
can be empty while waiting for a request to complete. But it should
nevertheless be possible.

Cheers!
Michael




Problem with nt acl support when saving Excel or Word Files

2003-02-11 Thread Michael Steffens
Hi,

does anyone have an idea concerning this one? Has anyone else also
seen these symptoms?

  http://lists.samba.org/pipermail/samba-technical/2003-January/041748.html

The problem described in this posting occurs here, too.

The situation: A user has read/write permissions on a Word/Excel file,
via group membership, but file owner and group are different from
the current UID and primary GID.

After editing and saving the file ACLs are broken, in one or the other
way, for all of NT4, W2k, and WinXP clients, but differently for all of
them. All clients do store by creating a temp file, first.

With NT4 the final owner and group is changed to the last writer,
but original user and group privileges don't make it into the new
ACL. Samba log reports it got SMB_ACL_GROUP_OBJ and SMB_ACL_USER_OBJ
for them, however. The new group has no write permissions.

With Win2k the final owner and group is changed to the last writer.
Previous user and group permissions are correctly transferred
to the resulting ACL. But the new owner gets write permissions
revoked.

With WinXP owner and group remain the same as in the original file.
Samba log reports it got SMB_ACL_GROUP_OBJ and SMB_ACL_USER_OBJ,
but actually setting them fails with Not owner on the temp file.
Nevertheless, the file group gets write permission revoked.

Being totally confused :)

Cheers!
Michael




Re: Problem with nt acl support when saving Excel or Word Files

2003-02-11 Thread Michael Steffens
Hi Don,

MCCALL,DON (HP-USA,ex1) wrote:

Hi Michael,
what's your umask for the users in question?


The umask at smbd's startup is 077, but one of the first actions of
smbd is setting it to zero. Are there any user specific umask settings
for smbd?

create mask is default (i.e. 0744). But according to smb.conf(5) it
should have no effect on NT ACLs. Wait a minute ... it could explain why
temp files are being created group read only. :)

But not why owner write permissions are revoked with W2k clients, and
previous user and group privileges not being replicated with NT4 and WinXP
clients. (Despite log indicates that clients are trying to do so.)

security mask is default, too, i.e. 0777.

Cheers!
Michael




Re: Problem with nt acl support when saving Excel or Word Files

2003-02-11 Thread Michael Steffens
Hi Jeff,

Jeff Mandel wrote:

I found this is office 2000 v 9.3821 SR1 (not the latest)
We are trying to load the latest office update to see if that fixes it 
first. Is anybody experiencing this with samba later than 9.4402 SR1 or 
on the latest version, whatever that is?

Would also prefer to find W2k or Office 2000 guilty (would be less work
for us), but having the vague feeling that it isn't.

Last weekend I could *very* partially fix the problem for W2k, when
force group is in effect.

Found in log that uid_entry_in_group() in smbd/posix_acls.c unsuccessfully
tried to lookup the current UID in the enforced group. I added a test
for exactly that configuration, and the revokation of owner write permissions
disappeared.

But, I do not really understand why it did, and it breaks on every other
configuration. And with force group ACLs are only half of the fun :)

Furthermore, ACLs of NT4 and WinXP clients end up incorrectly, too.
Previous owner and group permissions don't get transferred to the new
file. You can end up with the previous writer getting permissions
revoked, as the file's group changes to the GID of the last writer
(with NT4 and W2k, but not with WinXP).

On the other hand, in debug level 10, create_canon_ace_lists() always logs
that clients attempt to apply the corresponding allow ACEs. This part does
work correctly for W2k clients, however.

Cheers!
Michael




Re: REPOST: Finding group members - fix to winbindd_ads.c

2003-02-10 Thread Michael Steffens
Ken Cross wrote:

Currently, if you do WINBINDD_GETGRNAM to an NT domain using RPC, you
get *all* the members of a group, whether primary or supplemental.  

The same call to an AD using LDAP just returns supplemental members.

My patch causes the call to either an NT domain or AD to return the same
thing.  

There was some discussion about making it a separate call, but I think
that'd be a mistake.  It seems like they should be consistent.

Would like to add my two cents to the discussion, too :)

I think there are good reasons for the habit of not including
primary group members in /etc/group, which would also apply to
winbind getgrnam/getgrgid calls.

Many (if not most) invocations of getgrnam/getgrgid are for
GID - name conversions, where the list of group members
is just unnecessary load. Which can be reduced by omitting
primary group members.

It's a pity there are no widespread standard Unix calls for
these conversions without querying group members, but that's
a boundary condition which winbind can hardly get around.
Every ls -l gathers group member lists just to ignore
them, for example.

Furthermore, some platforms do have an implicit limitation
of group sizes, by providing a default fixed result buffer size,
which most callers of getgrnam/getgrgid (better: their reentrant
counterparts getgrnam_r/getgrgid_r) adhere to. Omitting primary
members makes hitting such limits less likely.

Cheers!
Michael




Re: REPOST: Finding group members - fix to winbindd_ads.c

2003-02-10 Thread Michael Steffens
Hello Ken,

Ken Cross wrote:

I don't disagree with anything you said.

However, we currently get different results from a getgrnam/getgrgid
depending on whether you net rpc join or net ads join.  That, IMHO,
is a Bad Thing.


Agreed 100%, too! :)

Wrote this because from previous postings I had the impressions that
most people are voting for unifying to inclusion of primary group members,
who also had their valid points.

But I think this way is not necessarily a good idea. Unifying the
behaviour *is* a good idea, for sure. :)

Cheers!
Michael



-Original Message-
From: Michael Steffens [mailto:[EMAIL PROTECTED]] 
Sent: Monday, February 10, 2003 7:20 AM
To: Ken Cross
Cc: 'Multiple recipients of list SAMBA-TECHNICAL'
Subject: Re: REPOST: Finding group members - fix to winbindd_ads.c


Ken Cross wrote:

Currently, if you do WINBINDD_GETGRNAM to an NT domain using RPC, you 
get *all* the members of a group, whether primary or supplemental.

The same call to an AD using LDAP just returns supplemental members.

My patch causes the call to either an NT domain or AD to return the 
same thing.

There was some discussion about making it a separate call, but I think



that'd be a mistake.  It seems like they should be consistent.



Would like to add my two cents to the discussion, too :)

I think there are good reasons for the habit of not including primary
group members in /etc/group, which would also apply to winbind
getgrnam/getgrgid calls.

Many (if not most) invocations of getgrnam/getgrgid are for
GID - name conversions, where the list of group members
is just unnecessary load. Which can be reduced by omitting primary group
members.

It's a pity there are no widespread standard Unix calls for these
conversions without querying group members, but that's a boundary
condition which winbind can hardly get around. Every ls -l gathers
group member lists just to ignore them, for example.

Furthermore, some platforms do have an implicit limitation
of group sizes, by providing a default fixed result buffer size, which
most callers of getgrnam/getgrgid (better: their reentrant counterparts
getgrnam_r/getgrgid_r) adhere to. Omitting primary members makes hitting
such limits less likely.

Cheers!
Michael






Re: Winbind on HPUX 11, some small progress

2003-02-06 Thread Michael Steffens
Esh, Andrew wrote:

I thought I was told early on in this discussion that HP-UX doesn't like
certain keywords in nsswitch.conf, and winbind is one of them. That being
the case, isn't libnss_winbind.1 useless?


Discovered recently that this is no longer true for 11.00. Patch PHCO_26089
is resolving the conflict with libpam_unix.1, such that one can configure
third party NSS backends honestly, without any faking around. :)

There is no such fix available for 11.11 yet, but I have been told it's
on the way.

Don's workaround using the -r option of the passwd command, explicitly
specifying the NSS backend to be used, does work on 11.11, however.
So one could already configure winbind NSS cleanly, provided PAM unix
password management is not required for anything else than the passwd
program.

Cheers!
Michael




Re: Bottleneck with Winbind and NT ACLs in 2.2.7a

2003-02-05 Thread Michael Steffens
Hi Jeremy,

[EMAIL PROTECTED] wrote:

Damn good idea ! I think I'll look into applying some version
of this - thanks !


Many thanks to you!

Our big boy unveiled another problem with winbind and a large
number of clients (most of them smbds, but also other processes,
of course): Winbindd becomes an excessive file descriptor
consumer for client sockets.

Each smbd wants two of them. And as long as client processes are
alive, client connections stay open even when being idle.

It is possible to increase the maxfiles kernel parameter (we
have set it to 300). But as every process can potentially become
a winbind client, it's hard to tell what the actual limit should
be. During the last three days our winbindd was already pretty
close to 300 open files under peak load :)

I think that winbindd could use some housekeeping of client
connections. In the attached patch I have tried to apply a
threshold method. As soon as a maximum number of clients is
exceeded, the oldest idle connection is looked up and shut
down. Criterion for a connection being considered idle is

 - empty read and write buffers
 - no get??ent environments

In case all connections are actually active, exceeding the
threshold is being allowed (hoping it's temporary).

Together with smbds caching id mappings, reducing the frequency
of queries, this could work without too much impact on client
processes (which re-open connections winbindd has closed
when required).

What do you think about it?

Cheers!
Michael

Index: source/nsswitch/winbindd.h
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd.h,v
retrieving revision 1.3.4.9
diff -u -r1.3.4.9 winbindd.h
--- source/nsswitch/winbindd.h  13 Sep 2002 23:46:27 -  1.3.4.9
+++ source/nsswitch/winbindd.h  5 Feb 2003 12:48:02 -
@@ -42,6 +42,7 @@
 struct winbindd_response response;/* Respose to client */
 struct getent_state *getpwent_state;  /* State for getpwent() */
 struct getent_state *getgrent_state;  /* State for getgrent() */
+time_t access;/* Time of last access (read or write) 
+*/
 };
 
 /* State between get{pw,gr}ent() calls */
@@ -189,6 +190,7 @@
 
 #define WINBINDD_ESTABLISH_LOOP 30
 #define DOM_SEQUENCE_NONE ((uint32)-1)
+#define WINBINDD_MAX_CLIENTS 100
 
 /* SETENV */
 #if HAVE_SETENV
Index: source/nsswitch/winbindd.c
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd.c,v
retrieving revision 1.3.2.35
diff -u -r1.3.2.35 winbindd.c
--- source/nsswitch/winbindd.c  3 Oct 2002 21:00:10 -   1.3.2.35
+++ source/nsswitch/winbindd.c  5 Feb 2003 12:48:03 -
@@ -343,6 +343,10 @@

ZERO_STRUCTP(state);
state-sock = sock;
+
+   /* give it a date of birth, such that it doesn't become a removal
+  candidate immediately */
+   state-access = time(NULL);

/* Add to connection list */

@@ -380,6 +384,36 @@
}
 }
 
+/* Shutdown client connection which has been idle for the longest time */
+
+static BOOL remove_idle_client(void) {
+   struct winbindd_cli_state *state, *remove_state = NULL;
+   time_t access = 0;
+   int nidle = 0;
+
+   for (state = client_list; state; state = state-next) {
+
+   if (state-read_buf_len == 0  state-write_buf_len == 0 
+   !state-getpwent_state  !state-getgrent_state) {
+
+   nidle++;
+   if (!access || state-access  access) {
+   access = state-access;
+   remove_state = state;
+   }
+   }
+   }
+
+   if (remove_state) {
+   DEBUG(5,(Found %d idle client connections, shutting down sock %d, pid 
+%d\n,
+nidle, remove_state-sock, remove_state-pid));
+   remove_client(remove_state);
+   return True;
+   }
+
+   return False;
+}
+
 /* Process a complete received packet from a client */
 
 static void process_packet(struct winbindd_cli_state *state)
@@ -427,6 +461,7 @@
/* Update client state */

state-read_buf_len += n;
+   state-access = time(NULL);
 }
 
 /* Write some data to a client connection */
@@ -479,6 +514,7 @@
/* Update client state */

state-write_buf_len -= num_written;
+   state-access = time(NULL);

/* Have we written all data? */

@@ -597,8 +633,15 @@
 
if (selret  0) {
 
-   if (FD_ISSET(accept_sock, r_fds))
+   if (FD_ISSET(accept_sock, r_fds)) {
+   while (num_clients  WINBINDD_MAX_CLIENTS - 1)
+   if (!remove_idle_client()) {
+   DEBUG(0,(Exceeding %d client 
+connections, no idle connection 

Bottleneck with Winbind and NT ACLs in 2.2.7a

2003-02-04 Thread Michael Steffens
Hi,

we are running a big Samba 2.2.7a server with Winbind (100 concurrent
users, 600 id mappings created since then) since last weekend.

It's running quite well! :)

However, users are complaining about Samba being very slow when
NT ACL support is enabled. I'm suspecting that winbindd is the
bottleneck.

In winbindd's log I can see that it has to serve [ug]id to sid
requests at a very high frequency. Most of them seem to be triggered
by smbd daemons working on POSIX ACLs, and the UIDs and GIDs
requested are almost always those of the user running a session.
Requests are keeping winbindd busy all the time. And when winbindd
is busy talking to DCs, user sessions have to wait for ACL settings
to complete.

As the ID mappings are static - as soon as they exist - wouldn't it
be a good idea to have smbd cache those it has come across in the
current session?

In the attached patch I have tried to implement such a local
mapping cache for smbd. What do you think about it?

Cheers!
Michael

Index: source/smbd/uid.c
===
RCS file: /cvsroot/samba/source/smbd/uid.c,v
retrieving revision 1.50.4.27
diff -u -r1.50.4.27 uid.c
--- source/smbd/uid.c   7 Jun 2002 03:49:15 -   1.50.4.27
+++ source/smbd/uid.c   4 Feb 2003 12:49:25 -
@@ -24,6 +24,164 @@
 /* what user is current? */
 extern struct current_user current_user;
 
+/* Id mapping cache.  This is to avoid Winbind mappings already
+   seen by smbd to be queried too frequently, keeping winbindd
+   busy, and blocking smbd while winbindd is busy with other
+   stuff. */
+
+#define UID_SID_CACHE_SIZE 256
+#define GID_SID_CACHE_SIZE 256
+
+static int n_uid_sid_cache = 0;
+static int n_gid_sid_cache = 0;
+
+static struct {uid_t uid; DOM_SID sid;} uid_sid_cache[UID_SID_CACHE_SIZE];
+static struct {gid_t gid; DOM_SID sid;} gid_sid_cache[GID_SID_CACHE_SIZE];
+
+
+/* convert uid to sid from cache */
+
+static BOOL fetch_sid_from_uid_cache(DOM_SID *psid, uid_t uid) {
+   int i;
+   fstring sid;
+
+   for (i = 0; i  n_uid_sid_cache; i++) {
+   if (uid_sid_cache[i].uid == uid) {
+   *psid = uid_sid_cache[i].sid;
+   DEBUG(3,(fetch sid from uid cache %u - %s\n,
+   (unsigned int)uid, sid_to_string(sid, psid)));
+   return TRUE;
+   }
+   }
+   return False;
+}
+
+
+/* convert sid to uid from cache */
+
+static BOOL fetch_uid_from_cache(uid_t *puid, DOM_SID *psid) {
+   int i;
+   fstring sid;
+
+   for (i = 0; i  n_uid_sid_cache; i++) {
+   if (sid_compare(uid_sid_cache[i].sid, psid) == 0) {
+   *puid = uid_sid_cache[i].uid;
+   DEBUG(3,(fetch uid from cache %u - %s\n,
+   (unsigned int)*puid, sid_to_string(sid, psid)));
+   return TRUE;
+   }
+   }
+   return False;
+}
+
+
+/* store uid mapping in cache */
+
+static void store_uid_sid_cache(DOM_SID *psid, uid_t uid) {
+   int i;
+   fstring sid;
+
+   /* first lookup whether cache entry already exists, */
+
+   for (i = 0; i  n_uid_sid_cache; i++) {
+   if (uid_sid_cache[i].uid == uid) {
+   if (sid_compare(psid, uid_sid_cache[i].sid)) {
+   DEBUG(0,(Warning: uid mapping has changed to %u - 
+%s\n,
+   (unsigned int)uid, sid_to_string(sid, psid)));
+   goto store;
+   }
+   return;
+   }
+   }
+   if (n_uid_sid_cache  UID_SID_CACHE_SIZE) {
+   i = n_uid_sid_cache++;
+   } else {
+   /* cache full, overwrite random old entry */
+   i = rand() % UID_SID_CACHE_SIZE;
+   DEBUG(3,(overwrite uid mapping [%d] in cache: %u - %s\n, i,
+   (unsigned int)uid_sid_cache[i].uid,
+   sid_to_string(sid, uid_sid_cache[i].sid)));
+   }
+
+ store:
+   uid_sid_cache[i].uid = uid;
+   uid_sid_cache[i].sid = *psid;
+   DEBUG(3,(store uid mapping in cache %u - %s\n,
+   (unsigned int)uid, sid_to_string(sid, psid)));
+}
+
+
+/* convert gid to sid from cache */
+
+static BOOL fetch_sid_from_gid_cache(DOM_SID *psid, gid_t gid) {
+   int i;
+   fstring sid;
+
+   for (i = 0; i  n_gid_sid_cache; i++) {
+   if (gid_sid_cache[i].gid == gid) {
+   *psid = gid_sid_cache[i].sid;
+   DEBUG(3,(fetch sid from gid cache %u - %s\n,
+   (unsigned int)gid, sid_to_string(sid, psid)));
+   return TRUE;
+   }
+   }
+   return False;
+}
+
+
+/* convert sid to gid from cache */
+
+static BOOL fetch_gid_from_cache(gid_t *pgid, DOM_SID *psid) {
+   int i;
+   fstring sid;
+
+   for (i = 

Re: Will these patches make it into 2.2.8?

2003-02-02 Thread Michael Steffens
Gerald (Jerry) Carter wrote:

On Fri, 31 Jan 2003 [EMAIL PROTECTED] wrote:



They are in my inbox queue of things to merge. I have to work on HP
printing bugs as my 'day' job priority, but I have not forgotten
these and will ensure they get added before 2.2.8



But probably not for 2.2.8pre1.


Oops, did it sound that impatient? Sorry, that was not intended.
Just didn't wan't to delay the question until one hour before
final release :)

Michael




Will these patches make it into 2.2.8?

2003-01-31 Thread Michael Steffens
Hi Samba team,

as 2.2.8 seems to approach now, have the following patches been
considered for it?  They both don't add functionality, but rather
improve robustness, and are platform independent:

  http://lists.samba.org/pipermail/samba-technical/2002-December/041413.html

prevents winbindd from damaging its own idmap TDB on write failures
(filesystem full), by rolling back partial changes done by the failed
store of mapping.

  http://lists.samba.org/pipermail/samba-technical/2003-January/041897.html

avoids the reconnect delay when DC pipes have died, thus avoids
false negatives to be returned to clients, and to be cached.

Not a 100%, however. If there is really no DC available at the time
of query, it will still happen. But it's an improvement compared
to having these false negatives always after a connection died.


Cheers!
Michael




Re: RE : [Samba] Winbind on HPUX11, Totally Stuck, Please Help

2003-01-28 Thread Michael Steffens
Hi Miles,

Miles Roper wrote:

Hi Drew,
 
No luck.
 
Pretty much done all that, still get all the same problems
 
That site was pretty good though :o)

There is one thing missing, however. If you fake winbind NSS to be
ldap, exported constructor names in winbind_nss_solaris.c also need
to be adjusted:

  _nss_winbind_passwd_constr  -  _nss_ldap_passwd_constr
  _nss_winbind_group_constr  -  _nss_ldap_group_constr

Just redirecting the symlink doesn't do.  Hmm, this tweaking
of winbind NSS constructors is awful, changing from correct to
wrong. :(

This is what I did:

 1. Create a copy of winbind_nss_solaris.c with a descriptive
name, like winbind_nss_solaris_fakeldap.c

 2. Do constructor replacements descriped above in the copy

 3. Build shared library with a descriptive name, like

  make nsswitch/winbind_nss_solaris_fakeldap.po \
   nsswitch/winbind_nss.po nsswitch/wb_common.po
  ld -b -B symbolic +h libnss_winbind_fakeldap.1 -o nsswitch/libnss_winbind_fakeldap.1 \
   nsswitch/winbind_nss_solaris_fakeldap.po nsswitch/winbind_nss.po \
   nsswitch/wb_common.po -lc

 4. Create symlink in /usr/lib

  libnss_ldap.1 - libnss_winbind_fakeldap.1

and leave original libnss_winbind.1 as it is.

This way gives a hint to administrators/supporters about what has
been tweaked, and it allows to revert the hack easily once the
conflict with libpam_unix.1 has been resolved.


Does anyone have an idea about the shell logging in?  Why do I keep on 
getting logged out?  Does the home directory need to be created, does it 
need a .profile?  What about the permissions?  I've tried creating one 
world writeable but no luck.

I did not see any dependeny to the home directory. If it doesn't
exist, or is not accessible, the user just gets a warning and is
being put to '/'.

But the login shell is important (template shell parameter).
If the shell doesn't exist, or happens to be /usr/bin/false,
you will get logged off immediately.

Cheers!
Michael

--
To unsubscribe from this list go to the following URL and read the
instructions:  http://lists.samba.org/mailman/listinfo/samba



Re: [Samba] RE: Winbind on HPUX11, Totally Stuck, Please Help

2003-01-28 Thread Michael Steffens
Ronan Waide wrote:

On January 28, [EMAIL PROTECTED] said:


I don't have HPUX, so I don't know what to suggest for that. I just know
getent won't work without winbindd in nsswitch.conf on Linux.



I think the point that was being made is that NSS support on HPUX only
supports a few known types, of which one is LDAP. The discussion was
basically about faking out the system so that what it thinks is LDAP
is actually winbind.


Yep. It's a HP-UX specific workaround. Please ignore it
everywhere else.

Michael


--
To unsubscribe from this list go to the following URL and read the
instructions:  http://lists.samba.org/mailman/listinfo/samba



Re: RE : [Samba] Winbind on HPUX11, Totally Stuck, Please Help

2003-01-28 Thread Michael Steffens
Hi Miles,

Miles Roper wrote:

Hi Drew,
 
No luck.
 
Pretty much done all that, still get all the same problems
 
That site was pretty good though :o)

There is one thing missing, however. If you fake winbind NSS to be
ldap, exported constructor names in winbind_nss_solaris.c also need
to be adjusted:

  _nss_winbind_passwd_constr  -  _nss_ldap_passwd_constr
  _nss_winbind_group_constr  -  _nss_ldap_group_constr

Just redirecting the symlink doesn't do.  Hmm, this tweaking
of winbind NSS constructors is awful, changing from correct to
wrong. :(

This is what I did:

 1. Create a copy of winbind_nss_solaris.c with a descriptive
name, like winbind_nss_solaris_fakeldap.c

 2. Do constructor replacements descriped above in the copy

 3. Build shared library with a descriptive name, like

  make nsswitch/winbind_nss_solaris_fakeldap.po \
   nsswitch/winbind_nss.po nsswitch/wb_common.po
  ld -b -B symbolic +h libnss_winbind_fakeldap.1 -o nsswitch/libnss_winbind_fakeldap.1 \
   nsswitch/winbind_nss_solaris_fakeldap.po nsswitch/winbind_nss.po \
   nsswitch/wb_common.po -lc

 4. Create symlink in /usr/lib

  libnss_ldap.1 - libnss_winbind_fakeldap.1

and leave original libnss_winbind.1 as it is.

This way gives a hint to administrators/supporters about what has
been tweaked, and it allows to revert the hack easily once the
conflict with libpam_unix.1 has been resolved.


Does anyone have an idea about the shell logging in?  Why do I keep on 
getting logged out?  Does the home directory need to be created, does it 
need a .profile?  What about the permissions?  I've tried creating one 
world writeable but no luck.

I did not see any dependeny to the home directory. If it doesn't
exist, or is not accessible, the user just gets a warning and is
being put to '/'.

But the login shell is important (template shell parameter).
If the shell doesn't exist, or happens to be /usr/bin/false,
you will get logged off immediately.

Cheers!
Michael




Re: [Samba] Winbind on HPUX11, Totally Stuck, Please Help

2003-01-26 Thread Michael Steffens
Hello Jennifer,

Jennifer Fountain wrote:

Miles,
I run samba (winbind) on hpux11 as well. do have this problem:  when you 
type $groups, you only get domain admins and no other groups or if you 
type groups user1, you get no groups?  but when you type ./wbinfo -g 
jfountain, you get all the groups in the gid format?  I am almost ready 
to give up and install it on linux! :(

Just a wild guess: I seems that the groups command is trying to resolve
group memberships using the setgrent/getgrent/endgrent combo of libc
calls. The getgrent call will fail for all groups, where the result size
exceeds the buffer provided by the groups command. Don't know how much
this is precisely, but if it is _SC_GETGR_R_SIZE_MAX (2048), and taking
into account the usual size of NT usernames including domain names,
a group must have quite few members to get displayed.

The wbinfo -g command does not use setgrent/getgrent/endgrent.

I have actually disabled everything involving winbind user or group
enumeration, as it exhausts resources very quickly in our environment.

But I'm assuming it would do the same under Linux...

Michael

--
To unsubscribe from this list go to the following URL and read the
instructions:  http://lists.samba.org/mailman/listinfo/samba



Winbind reconnect failures

2003-01-24 Thread Michael Steffens
Hi,

since quite some time I was observing an intermittant (thus
annoying) problem. Winbindd apparently loses connections to DCs
now and then. As multiple winbind instances are affected
simultanously, I suppose the reason for connections dying is
external. But they all fail to reconnect, then. Winbindd restart
always fixed it, but this can't be the solution.

Digged into it (after learning how to disconnect a TCP link
without killing the process owning the socket on HP-UX :).

The reason seems to be, that the retry code in

  cm_get_lsa_handle()
  cm_get_sam_handle()

in winbindd_cm.c does not actually get executed. After a
connection died, but before an actual read or write is attempted,
the cached handle is still ok for policy_handle_is_valid(), and
the functions above return with success, without trying to write
to the corresponding pipe.

As a result, functions in winbindd_rpc.c do fail on subsequent
rpc calls, but without retrying.

A solution - if we don't want cm_get_*_handle() to probe pipes
on every invocation - would be to move retry triggers to their
callers.

Did so. Attached patch is for 2.2. If I have seen correctly
in CVS, however, 3.0 should suffer from the same problem.

Adds a lot of stupid code, unfortunately, as every caller needs
to be equipped individually. Maybe there is a more elegant way?
But it seems to work fine here.

(The retry code in cm_get_*_handle() seems redundant with the
patch applied, but it doesn't hurt. Didn't change it.)

Cheers!
Michael




Index: source/nsswitch/winbindd_rpc.c
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd_rpc.c,v
retrieving revision 1.22.2.13
diff -u -r1.22.2.13 winbindd_rpc.c
--- source/nsswitch/winbindd_rpc.c  6 Jan 2003 07:33:13 -   1.22.2.13
+++ source/nsswitch/winbindd_rpc.c  24 Jan 2003 09:51:22 -
@@ -52,12 +52,16 @@
CLI_POLICY_HND *hnd;
NTSTATUS result;
POLICY_HND dom_pol;
-   BOOL got_dom_pol = False;
+   BOOL got_dom_pol;
uint32 des_access = SEC_RIGHTS_MAXIMUM_ALLOWED;
int i;
+   BOOL do_retry = True;
 
+ retry:
+   hnd = NULL;
*num_entries = 0;
*info = NULL;
+   got_dom_pol = False;
 
/* Get sam handle */
 
@@ -132,6 +136,14 @@
if (got_dom_pol)
cli_samr_close(hnd-cli, mem_ctx, dom_pol);
 
+   if (!NT_STATUS_IS_OK(result)  do_retry 
+   hnd  hnd-cli  hnd-cli-fd == -1) {
+   DEBUG(3, (Failed with %s for domain %s, retrying\n, 
+ nt_errstr(result), domain));
+   do_retry = False;
+   goto retry;
+   }
+
return result;
 }
 
@@ -147,18 +159,21 @@
POLICY_HND dom_pol;
NTSTATUS result;
uint32 start = 0;
+   BOOL do_retry = True;
 
+ retry:
+   hnd = NULL;
*num_entries = 0;
*info = NULL;
 
if (!NT_STATUS_IS_OK(result = cm_get_sam_handle(domain-name, hnd)))
-   return result;
+   goto done;
 
result = cli_samr_open_domain(hnd-cli, mem_ctx,
  hnd-pol, des_access, domain-sid, dom_pol);
 
if (!NT_STATUS_IS_OK(result))
-   return result;
+   goto done;
 
do {
struct acct_info *info2 = NULL;
@@ -193,6 +208,16 @@
 
cli_samr_close(hnd-cli, mem_ctx, dom_pol);
 
+ done:
+
+   if (!NT_STATUS_IS_OK(result)  do_retry 
+   hnd  hnd-cli  hnd-cli-fd == -1) {
+   DEBUG(3, (Failed with %s for domain %s, retrying\n, 
+ nt_errstr(result), domain));
+   do_retry = False;
+   goto retry;
+   }
+
return result;
 }
 
@@ -205,26 +230,32 @@
TALLOC_CTX *mem_ctx;
CLI_POLICY_HND *hnd;
NTSTATUS result;
-   DOM_SID *sids = NULL;
-   uint32 *types = NULL;
+   DOM_SID *sids;
+   uint32 *types;
const char *full_name;
+   BOOL do_retry = True;
 
if (!(mem_ctx = talloc_init_named(name_to_sid[rpc] for [%s]\\[%s], 
domain-name, name))) {
DEBUG(0, (talloc_init failed!\n));
return NT_STATUS_NO_MEMORY;
}
 
+ retry:
+   hnd = NULL;
+   sids = NULL;
+   types = NULL;
+
if (!NT_STATUS_IS_OK(result = cm_get_lsa_handle(domain-name, hnd))) {
-   talloc_destroy(mem_ctx);
-   return NT_STATUS_UNSUCCESSFUL;
+   result = NT_STATUS_UNSUCCESSFUL;
+   goto done;
}
 
full_name = talloc_asprintf(mem_ctx, %s\\%s, domain-name, name);

if (!full_name) {
DEBUG(0, (talloc_asprintf failed!\n));
-   talloc_destroy(mem_ctx);
-   return NT_STATUS_NO_MEMORY;
+   result = NT_STATUS_NO_MEMORY;
+   goto done;
}
 
result = cli_lsa_lookup_names(hnd-cli, mem_ctx, hnd-pol, 1, 
@@ 

Re: Winbind reconnect failures

2003-01-24 Thread Michael Steffens
Celebrated too early. In sequence_number() hnd was not
initialized, and its value not tested when checking
whether to retry.

Result: bus error when querying a non-existent domain. Grr...

Corrected patch is attached. Sorry!
Michael

Index: source/nsswitch/winbindd_rpc.c
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd_rpc.c,v
retrieving revision 1.22.2.13
diff -u -r1.22.2.13 winbindd_rpc.c
--- source/nsswitch/winbindd_rpc.c  6 Jan 2003 07:33:13 -   1.22.2.13
+++ source/nsswitch/winbindd_rpc.c  24 Jan 2003 16:23:33 -
@@ -52,12 +52,16 @@
CLI_POLICY_HND *hnd;
NTSTATUS result;
POLICY_HND dom_pol;
-   BOOL got_dom_pol = False;
+   BOOL got_dom_pol;
uint32 des_access = SEC_RIGHTS_MAXIMUM_ALLOWED;
int i;
+   BOOL do_retry = True;
 
+ retry:
+   hnd = NULL;
*num_entries = 0;
*info = NULL;
+   got_dom_pol = False;
 
/* Get sam handle */
 
@@ -132,6 +136,14 @@
if (got_dom_pol)
cli_samr_close(hnd-cli, mem_ctx, dom_pol);
 
+   if (!NT_STATUS_IS_OK(result)  do_retry 
+   hnd  hnd-cli  hnd-cli-fd == -1) {
+   DEBUG(3, (Failed with %s for domain %s, retrying\n, 
+ nt_errstr(result), domain));
+   do_retry = False;
+   goto retry;
+   }
+
return result;
 }
 
@@ -147,18 +159,21 @@
POLICY_HND dom_pol;
NTSTATUS result;
uint32 start = 0;
+   BOOL do_retry = True;
 
+ retry:
+   hnd = NULL;
*num_entries = 0;
*info = NULL;
 
if (!NT_STATUS_IS_OK(result = cm_get_sam_handle(domain-name, hnd)))
-   return result;
+   goto done;
 
result = cli_samr_open_domain(hnd-cli, mem_ctx,
  hnd-pol, des_access, domain-sid, dom_pol);
 
if (!NT_STATUS_IS_OK(result))
-   return result;
+   goto done;
 
do {
struct acct_info *info2 = NULL;
@@ -193,6 +208,16 @@
 
cli_samr_close(hnd-cli, mem_ctx, dom_pol);
 
+ done:
+
+   if (!NT_STATUS_IS_OK(result)  do_retry 
+   hnd  hnd-cli  hnd-cli-fd == -1) {
+   DEBUG(3, (Failed with %s for domain %s, retrying\n, 
+ nt_errstr(result), domain));
+   do_retry = False;
+   goto retry;
+   }
+
return result;
 }
 
@@ -205,26 +230,32 @@
TALLOC_CTX *mem_ctx;
CLI_POLICY_HND *hnd;
NTSTATUS result;
-   DOM_SID *sids = NULL;
-   uint32 *types = NULL;
+   DOM_SID *sids;
+   uint32 *types;
const char *full_name;
+   BOOL do_retry = True;
 
if (!(mem_ctx = talloc_init_named(name_to_sid[rpc] for [%s]\\[%s], 
domain-name, name))) {
DEBUG(0, (talloc_init failed!\n));
return NT_STATUS_NO_MEMORY;
}
 
+ retry:
+   hnd = NULL;
+   sids = NULL;
+   types = NULL;
+
if (!NT_STATUS_IS_OK(result = cm_get_lsa_handle(domain-name, hnd))) {
-   talloc_destroy(mem_ctx);
-   return NT_STATUS_UNSUCCESSFUL;
+   result = NT_STATUS_UNSUCCESSFUL;
+   goto done;
}
 
full_name = talloc_asprintf(mem_ctx, %s\\%s, domain-name, name);

if (!full_name) {
DEBUG(0, (talloc_asprintf failed!\n));
-   talloc_destroy(mem_ctx);
-   return NT_STATUS_NO_MEMORY;
+   result = NT_STATUS_NO_MEMORY;
+   goto done;
}
 
result = cli_lsa_lookup_names(hnd-cli, mem_ctx, hnd-pol, 1, 
@@ -237,6 +268,16 @@
*type = types[0];
}
 
+ done:
+
+   if (!NT_STATUS_IS_OK(result)  do_retry 
+   hnd  hnd-cli  hnd-cli-fd == -1) {
+   DEBUG(3, (Failed with %s for domain %s, retrying\n, 
+ nt_errstr(result), domain));
+   do_retry = False;
+   goto retry;
+   }
+
talloc_destroy(mem_ctx);
return result;
 }
@@ -255,9 +296,15 @@
char **names;
uint32 *types;
NTSTATUS result;
+   BOOL do_retry = True;
 
-   if (!NT_STATUS_IS_OK(result = cm_get_lsa_handle(domain-name, hnd)))
-   return NT_STATUS_UNSUCCESSFUL;
+ retry:
+   hnd = NULL;
+
+   if (!NT_STATUS_IS_OK(result = cm_get_lsa_handle(domain-name, hnd))) {
+   result = NT_STATUS_UNSUCCESSFUL;
+   goto done;
+   }
 
result = cli_lsa_lookup_sids(hnd-cli, mem_ctx, hnd-pol,
 1, sid, domains, names, types);
@@ -270,10 +317,21 @@
/* Paranoia */
if (strcasecmp(domain-name, domains[0]) != 0) {
DEBUG(1, (domain name from domain param and PDC lookup return 
differ! (%s vs %s)\n, domain-name, domains[0]));
-

Re: Prevent winbind idmap corruption

2003-01-07 Thread Michael Steffens
Andrew Bartlett wrote:

This looks like a good idea - getting this stuff right does matter...


Even more since this db is very hard to recover with Samba onboard
facilities...



I don't like the use of uid_t for gid_t, on the assumption that they
must be the same...  I know it will never happen, but it just seems the
wrong way to go about it.  As you assume an int32 below, then maybe make
it an int32 in the paramaters.


The deallocate_id function was derived quite straightforward from
its allocate_id counterpart, using the same types. The use of types
is not nice, agreed.



However, why do we need to 'roll back' the High Water Mark at all?

Instead, I would avoid the extra operation (if something failed already,
then don't risk that something else could fail too) and just leave that
uid/gid 'dead'.


This is something I would like to avoid, as UIDs and GIDs from winbind's
pool are limited resources, and are consumed unattended on client demand.
Extending the pool after IDs have been allocated and are in use will
often be difficult. Extending upwards is possible (if IDs directly above
are otherwise unused), while extending downwards or shifting is *very*
hard.

So at least when the failure is caused by a temporary and relatively harmless
condition like a full filesystem, a client attempting to connect again and
again should not be able to eat IDs endlessly.

In case of more serious failures, like disk defects or TDB internal
corruption, automatic recovery is difficult anyway, with or without
rollback of HWMs. I think best would be to have winbind stop and complain
then.

But some of these conditions are hard to detect, as the tdb_store_* routines
return IO error also when being unable to extend the TDB file due to lack
of diskspace.

In any case, with serious idmap database damage, there is no way around
rebuilding the TDB. Either with potential data loss from a previous snapshot
backup, or without data loss from a log, like

  http://lists.samba.org/pipermail/samba-technical/2002-April/036378.html

But the latter one has not become very popular...

Michael




Re: Prevent winbind idmap corruption

2002-12-19 Thread Michael Steffens
Ooops, bug in patch: Duplicate deletion of mapping on
rollback. Corrected version is attached. Sorry!

Michael

Index: nsswitch/winbindd_idmap.c
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd_idmap.c,v
retrieving revision 1.3.4.13
diff -u -r1.3.4.13 winbindd_idmap.c
--- nsswitch/winbindd_idmap.c   27 Apr 2002 03:04:08 -  1.3.4.13
+++ nsswitch/winbindd_idmap.c   19 Dec 2002 12:32:25 -
@@ -44,6 +44,8 @@
 
 if ((hwm = tdb_fetch_int32(idmap_tdb, 
  isgroup ? HWM_GROUP : HWM_USER)) == -1) {
+DEBUG(0, (Failed to fetch %s : %s\n, isgroup ? HWM_GROUP : HWM_USER,
+tdb_errorstr(idmap_tdb)));
 return False;
 }
 
@@ -63,7 +65,45 @@
 
 /* Store new high water mark */
 
-tdb_store_int32(idmap_tdb, isgroup ? HWM_GROUP : HWM_USER, hwm);
+if (tdb_store_int32(idmap_tdb, isgroup ? HWM_GROUP : HWM_USER, hwm)) {
+DEBUG(0, (Failed to store %s %d : %s\n, isgroup ? HWM_GROUP : HWM_USER,
+hwm, tdb_errorstr(idmap_tdb)));
+return False;
+}
+
+return True;
+}
+
+/* Deallocate either a user or group id, used for failure rollback */
+
+static BOOL deallocate_id(uid_t id, BOOL isgroup)
+{
+int hwm;
+
+/* Get current high water mark */
+
+if ((hwm = tdb_fetch_int32(idmap_tdb, 
+ isgroup ? HWM_GROUP : HWM_USER)) == -1) {
+DEBUG(0, (Failed to fetch %s : %s\n, isgroup ? HWM_GROUP : HWM_USER,
+tdb_errorstr(idmap_tdb)));
+return False;
+}
+
+if (hwm != id + 1) {
+/* Should actually never happen, internal redundancy... */
+DEBUG(0, (winbind %s mismatch on deallocation!\n, isgroup ? HWM_GROUP : 
+HWM_USER));
+return False;
+}
+
+hwm--;
+
+/* Store new high water mark */
+
+if (tdb_store_int32(idmap_tdb, isgroup ? HWM_GROUP : HWM_USER, hwm)) {
+DEBUG(0, (Failed to store %s %d : %s\n, isgroup ? HWM_GROUP : HWM_USER,
+   hwm, tdb_errorstr(idmap_tdb)));
+return False;
+}
 
 return True;
 }
@@ -109,16 +149,36 @@
 fstring keystr2;
 
 /* Store new id */
-
+
 slprintf(keystr2, sizeof(keystr2), %s %d, isgroup ? GID : UID, *id);
 
 data.dptr = keystr2;
 data.dsize = strlen(keystr2) + 1;
 
-tdb_store(idmap_tdb, key, data, TDB_REPLACE);
-tdb_store(idmap_tdb, data, key, TDB_REPLACE);
+/* If any of the following actions fails try to
+   revert modifications successfully made so far. */
 
 result = True;
+
+if (result  tdb_store(idmap_tdb, key, data, TDB_REPLACE)) {
+DEBUG(0, (Failed to store id mapping %s:%s : %s\n,
+  key.dptr, data.dptr, tdb_errorstr(idmap_tdb)));
+
+if (!deallocate_id(*id, isgroup))
+DEBUG(0, (Failed to rollback id mapping\n));
+
+result = False;
+}
+
+if (result  tdb_store(idmap_tdb, data, key, TDB_REPLACE)) {
+DEBUG(0, (Failed to store reverse id mapping %s:%s : %s\n,
+  data.dptr, key.dptr, tdb_errorstr(idmap_tdb)));
+
+if (!deallocate_id(*id, isgroup) || tdb_delete(idmap_tdb, key))
+DEBUG(0, (Failed to rollback id mapping\n));
+
+result = False;
+}
 }
 }
 



Prevent winbind idmap corruption

2002-12-18 Thread Michael Steffens
Hi,

the attached patch prevents winbindd from corrupting the
id mapping database in case of write failure. For example when
the filesystem hosting the TDB file is full.

Storing a new meapping consists of three steps

 1. allocate UID/GID (increment HWM)
 2. store mapping UID/GID : SID
 3. store reverse mapping SID : UID/GID

which should be done as a transaction, either completely or not
at all.

The present winbindd_idmap.c does not check success of the
operations above, and will result in an inconsistent mapping
database when any of them fails.

The patched version does check success, and rolls back in
case of failure.

It's not 100% failure proof (transaction is not atomic), but
better than before IMO. :)

Michael


Index: nsswitch/winbindd_idmap.c
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd_idmap.c,v
retrieving revision 1.3.4.13
diff -u -r1.3.4.13 winbindd_idmap.c
--- nsswitch/winbindd_idmap.c   27 Apr 2002 03:04:08 -  1.3.4.13
+++ nsswitch/winbindd_idmap.c   18 Dec 2002 14:51:08 -
@@ -44,6 +44,8 @@
 
 if ((hwm = tdb_fetch_int32(idmap_tdb, 
  isgroup ? HWM_GROUP : HWM_USER)) == -1) {
+DEBUG(0, (Failed to fetch %s : %s\n, isgroup ? HWM_GROUP : HWM_USER,
+tdb_errorstr(idmap_tdb)));
 return False;
 }
 
@@ -63,7 +65,45 @@
 
 /* Store new high water mark */
 
-tdb_store_int32(idmap_tdb, isgroup ? HWM_GROUP : HWM_USER, hwm);
+if (tdb_store_int32(idmap_tdb, isgroup ? HWM_GROUP : HWM_USER, hwm)) {
+DEBUG(0, (Failed to store %s %d : %s\n, isgroup ? HWM_GROUP : HWM_USER,
+hwm, tdb_errorstr(idmap_tdb)));
+return False;
+}
+
+return True;
+}
+
+/* Deallocate either a user or group id, used for failure rollback */
+
+static BOOL deallocate_id(uid_t id, BOOL isgroup)
+{
+int hwm;
+
+/* Get current high water mark */
+
+if ((hwm = tdb_fetch_int32(idmap_tdb, 
+ isgroup ? HWM_GROUP : HWM_USER)) == -1) {
+DEBUG(0, (Failed to fetch %s : %s\n, isgroup ? HWM_GROUP : HWM_USER,
+tdb_errorstr(idmap_tdb)));
+return False;
+}
+
+if (hwm != id + 1) {
+/* Should actually never happen, internal redundancy... */
+DEBUG(0, (winbind %s mismatch on deallocation!\n, isgroup ? HWM_GROUP : 
+HWM_USER));
+return False;
+}
+
+hwm--;
+
+/* Store new high water mark */
+
+if (tdb_store_int32(idmap_tdb, isgroup ? HWM_GROUP : HWM_USER, hwm)) {
+DEBUG(0, (Failed to store %s %d : %s\n, isgroup ? HWM_GROUP : HWM_USER,
+   hwm, tdb_errorstr(idmap_tdb)));
+return False;
+}
 
 return True;
 }
@@ -109,16 +149,37 @@
 fstring keystr2;
 
 /* Store new id */
-
+
 slprintf(keystr2, sizeof(keystr2), %s %d, isgroup ? GID : UID, *id);
 
 data.dptr = keystr2;
 data.dsize = strlen(keystr2) + 1;
 
-tdb_store(idmap_tdb, key, data, TDB_REPLACE);
-tdb_store(idmap_tdb, data, key, TDB_REPLACE);
+/* If any of the following actions fails try to
+   revert modifications successfully made so far. */
 
 result = True;
+
+if (result  tdb_store(idmap_tdb, key, data, TDB_REPLACE)) {
+DEBUG(0, (Failed to store id mapping %s:%s : %s\n,
+  key.dptr, data.dptr, tdb_errorstr(idmap_tdb)));
+
+if (!deallocate_id(*id, isgroup))
+DEBUG(0, (Failed to rollback id mapping\n));
+
+result = False;
+}
+
+if (result  tdb_store(idmap_tdb, data, key, TDB_REPLACE)) {
+DEBUG(0, (Failed to store reverse id mapping %s:%s : %s\n,
+  data.dptr, key.dptr, tdb_errorstr(idmap_tdb)));
+
+if (!deallocate_id(*id, isgroup) || tdb_delete(idmap_tdb, key))
+DEBUG(0, (Failed to rollback id mapping\n));
+
+tdb_delete(idmap_tdb, key);
+result = False;
+}
 }
 }
 



Re: STAT_ST_BLOCKSIZE on HP-UX

2002-12-09 Thread Michael Steffens
[EMAIL PROTECTED] wrote:

It remained on 8192 for HP-UX (which is the number given
by st_blksize) and which seems to be just as wrong there.
The correct unit of st_blocks is 1024, instead.



I got this value from the HPUX team (who site near me in
Cupertino) but I'll check again


I first deduced the value by correlating st_blocks with
st_size, and the output of du -k, respectively.

Searched documentation about the correct value and found
an old support call stating

  Anyway, st_blocks is measured in DEV_BSIZE units (sys/param.h),
  which on HPUX is 1k.

Maybe this is the answer also for other platforms? At least
on Linux and Solaris /usr/include/sys/param.h also contained
correct values (512). On AIX it is in /usr/include/sys/dir.h.

Michael






STAT_ST_BLOCKSIZE on HP-UX

2002-12-04 Thread Michael Steffens
Hi,

noticed that very recently a bunch of patches was checked
in the SAMBA_2_2 CVS tree, correcting STAT_ST_BLOCKSIZE
to be 512 for a number of platforms. (see configure and
configure.in)

It remained on 8192 for HP-UX (which is the number given
by st_blksize) and which seems to be just as wrong there.
The correct unit of st_blocks is 1024, instead.

Cheers!
Michael




Group Domain Users

2002-11-11 Thread Michael Steffens
Hi,

recently David Shapiro complained about getent group not working
in large domain groups, in particular Domain Users:

 http://lists.samba.org/pipermail/samba-technical/2002-November/040646.html

I was facing the same problem, which I found annoying because it
always blocks winbindd without producing anything, while applications
like ls just wanted to determine group names. Which occurs frequently,
because Domain Users has been selected as default primary group.

And it will hardly ever succeed, as large domains quickly exceed
buffer sizes provided by applications or libc for getgrgid()
or getgrgid_r().

Resolved the problem in my local version by modifying winbindd_group.c
such that domain groups Domain Users will never get members filled
in the result. This is somewhat anologous to the habit not to
list primary group members in /etc/group in order not to exceed
maximum group sizes on systems with many local users.

Not ideal, not elegant, but it happens to produce the desired result :)

In the attached patches I also disabled enumeration of domain
users and groups in winbindd_list_users() and winbindd_list_groups()
depending on parameters winbind enum users and winbind enum groups.

It's done the same way as in winbindd_setpwent() and winbindd_setgrent().

Reason: processing these requests take extremely long in our environment
(hours to days), while winbindd will block other requests. And it won't
stop when a user of, for example, wbinfo -u aborts his request by
killing wbinfo. You would need to kill winbindd and restart it for
domain users to be able to log on again.

Cheers!
Michael





Index: source/nsswitch/winbindd_group.c
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd_group.c,v
retrieving revision 1.3.4.25
diff -u -r1.3.4.25 winbindd_group.c
--- source/nsswitch/winbindd_group.c14 Oct 2002 03:00:14 -  1.3.4.25
+++ source/nsswitch/winbindd_group.c11 Nov 2002 11:40:25 -
 -77,6 +77,17 
 goto done;
}
 
+   /* Always skip members of Domain Users */
+
+   if (group_rid == DOMAIN_GROUP_RID_USERS) {
+   DEBUG(10, (skip enumerating members of %s\\Domain Users\n, 
+ domain-name));
+   *gr_mem_len = 0;
+   *gr_mem = NULL;
+   result = True;
+   goto done;
+   }
+
/* Lookup group members */
status = domain-methods-lookup_groupmem(domain, mem_ctx, group_rid, 
num_names, 
  rid_mem, names, name_types);
 -690,6 +701,11 
int extra_data_len = 0, i;
 
DEBUG(3, ([%5d]: list groups\n, state-pid));
+
+   /* Check user has enabled this */
+
+   if (!lp_winbind_enum_groups())
+   return WINBINDD_ERROR;
 
/* Enumerate over trusted domains */
 

Index: source/nsswitch/winbindd_user.c
===
RCS file: /cvsroot/samba/source/nsswitch/winbindd_user.c,v
retrieving revision 1.3.4.17
diff -u -r1.3.4.17 winbindd_user.c
--- source/nsswitch/winbindd_user.c 14 Oct 2002 03:00:14 -  1.3.4.17
+++ source/nsswitch/winbindd_user.c 11 Nov 2002 11:41:11 -
 -556,6 +556,11 
 
DEBUG(3, ([%5d]: list users\n, state-pid));
 
+   /* Check user has enabled this */
+
+   if (!lp_winbind_enum_users())
+   return WINBINDD_ERROR;
+
if (!(mem_ctx = talloc_init_named(winbindd_list_users)))
return WINBINDD_ERROR;
 



Re: Group Domain Users

2002-11-11 Thread Michael Steffens
Tim Potter wrote:

On Mon, Nov 11, 2002 at 01:40:25PM +0100, Michael Steffens wrote:
The winbind enum users/groups parameter deliberately doesn't stop wbinfo
from listing the groups so there is at least one way to enumerate users
and groups.  

Yes, but specifically in an environment where domains are very large,
with many trust relationships, and with domain controllers being distributed
all over the world, benefits of this possibilty doesn't outweigh the costs
any more.



The fact that a client disconnecting doesn't stop winbindd is a bug in 
winbindd but I think it will be hard to fix properly.

With excessively long queries being disabled it isn't that dramatic
for me.

BTW: I love Winbind! :))




Winbind idmap recovery (wbidmap)

2002-04-30 Thread Michael Steffens

Hello Tim, hello everyone,

in February I have posted a winbind idmap recovery tool (wbidmap)
for dumping and restoring the id mapping tdb, plus a patch for
winbindd_idmap.c to enable logging of newly created mappings in
a way that can be replayed by wbidmap.

Has this approach been considered in the meanwhile?

No, I won't ask for getting it into 2.2.4 at this point :)

But in any case, for everyone who found it useful, I have updated
it for 2.2.4 (int32 instead of int value byte order, the
IDMAP_VERSION key, and the modified SID format).

Attached is the source file wbidmap.c, a patch for Makefile.in
such that it can be built using make bin/wbidmap, and the logging
patch against current winbindd_idmap.c.

Cheers!
Michael

/*
   Unix SMB/Netbios implementation.
   Version 2.0

   Winbind idmap tdb manipulation program.

   Michael Steffens [EMAIL PROTECTED]
   Copyright (C) Hewlett-Packard 2002

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/

#include includes.h

#define IDMAP_VERSION_KEY IDMAP_VERSION
#define IDMAP_VERSION 2

/* High water mark keys */

#define HWM_GROUP  GROUP HWM
#define HWM_USER   USER HWM

/* idmap TDB key/data types */

#define TYPE_UNKNOWN0
#define TYPE_HWM1
#define TYPE_UID2
#define TYPE_SID3
#define TYPE_VERSION4

/* Globals */

static TDB_CONTEXT *idmap_tdb = NULL;
static char *tdb_file = NULL;
static BOOL do_preview= False;
static BOOL do_dump   = False;
static BOOL do_create = False;
static BOOL do_merge  = False;
static BOOL do_overwrite  = False;
static BOOL do_terminate  = False;


/* We need a termination signal handler to avoid getting interrupted
   while inserting/deleting idmap pairs */

static void termination_handler(int signum)
{
do_terminate = True;
}


/* Print program usage */

static void usage(void)
{
fprintf(stderr, Usage: wbidmap [-f file] -d | -c | -m[op]\n);
fprintf(stderr, \t-f file\t\t\tuse file as mapping TDB (default %s)\n,
lock_path(winbindd_idmap.tdb));
fprintf(stderr, \t-d\t\t\tdump TDB mappings to stdout\n);
fprintf(stderr, \t-c\t\t\tcreate new mapping TDB from stdin\n);
fprintf(stderr, \t-m\t\t\tmerge stdin into mapping TDB\n);
fprintf(stderr, \t-o\t\t\toverwrite conflicting mappings in TDB on merge\n);
fprintf(stderr, \t-p\t\t\tpreview, do not change TDB on merge\n);
}


/* Return True if s is a valid decimal as UID/GID or RID value. No leading
   zeroes are allowed, unless the entire number is zero.  s is parsed until
   a '\0' character is encountered, but at most size characters. */

BOOL is_decimal(const char *s, int size)
{
const char *c;
int i = 0;

if (size = 0)
return False;
c = s;
do {
if (strchr(0123456789, *c) == 0)
return False;
c++;
i++;
} while (i  size  *c);

/* accept leading '0' only if it's the only didgit */
if (*s == '0'  i  1)
return False;
return True;
}


/* Parse data for type, whether it's UID/GID, SID, or HWM. UID and GID
   are of same type TYPE_UID (read it as UnixID :-), and are distinguished
   via isgroup. For TYPE_UID the numerical ID is returned in value. */

int type_tdb_data(TDB_DATA data, BOOL *isgroup, int *value)
{
int i;

if (!data.dptr)
return TYPE_UNKNOWN;
if (data.dsize == (strlen(IDMAP_VERSION_KEY) + 1)  strncmp(data.dptr, IDMAP_VERSION_KEY, strlen(IDMAP_VERSION_KEY)) == 0) {
return TYPE_VERSION;
}
if (data.dsize == (strlen(HWM_USER) + 1)  strncmp(data.dptr, HWM_USER, strlen(HWM_USER)) == 0) {
if (isgroup)
*isgroup = False;
return TYPE_HWM;
}
if (data.dsize == (strlen(HWM_GROUP) + 1)  strncmp(data.dptr, HWM_GROUP, strlen(HWM_GROUP)) == 0) {
if (isgroup)
*isgroup = True;
return TYPE_HWM;
}
if (data.dsize  5  strncmp(data.dptr, UID , 4) == 0  is_decimal(data.dptr + 4, data.dsize - 4)) {
if (value)
*value = strtol(data.dptr + 4, NULL, 10);
if (isgroup)
*isgroup = False;
return TYPE_UID;
}
if (data.dsize  5  strncmp(data.dptr, GID , 4) == 0  is_decimal(data.dptr + 4, data.dsize - 4)) {
if (value)
*value = strtol(data.dptr + 4, NULL, 10);
if (isgroup