Re: dynamically loadable named pipe providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Our (revised) funnel now works fairly closely to the TNG model, in which a domain socket is opened to the RPC server and the security context is passed as a preamble to the first RPC PDU. (Of course, our security context token probably doesn't look the same as the TNG one.) This way you would have a lot less GPL problems :-) If I remember correctly our idea had been a bit different. The idea was to load dynamic objects into the main smbd. All dynamic objects would reside in a special directory. A pipe is to be opened, smbd looks into a table of already loaded objects. If it's not loaded a libpipe_lsass.so (or so) is looked for and loaded on demand. This way the security issues look a lot simpler. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE9+G6QOmSXH9Mhhs8RAiRtAJ9vx6msYXZYKyxxKdqZ+NY8rRD5TgCgkXAB MCkQ1DwWfQY4GC7SKOZD8Zs= =JR+r -END PGP SIGNATURE-
Re: dynamically loadable named pipe providers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, I've heard that this is the case. The point I was trying to make for the sake of argument is that one can treat SMB as transport as one would TCP/IP. Ok. I was only trying to find out what you can do without port 135. BTW, Ethereal does not speak much about MAPI... While we have implemetned named pipes on top of UNIX domain sockets, it is important to note that they are logically distinct from raw DCE RPC over domain sockets (ncalrpc). Non-named pipe clients must make a DCE RPC BIND or ALTER_CONTEXT in order to authenticate themselves to the RPC server. Ah, ok. Sounds reasonable. Although I'm not really the one to argue about that. I have not looked at DCE RPC enough to really know what's going on and how much of it is in actual use. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE9+JG8OmSXH9Mhhs8RAtfdAJ9c3DwQ62+4RUdzuvFOKIm/sruI2QCgmkCU jtCDXupgXClpebcBNyW49lU= =3Erv -END PGP SIGNATURE-
Patch for 3_0 configure.in ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I've never done anything in configure.in. What about the following? Index: configure.in === RCS file: /kunden/vl/cvs/samba/source/configure.in,v retrieving revision 1.300.2.25 diff -u -r1.300.2.25 configure.in - --- configure.in2002/12/04 19:47:01 1.300.2.25 +++ configure.in2002/12/05 10:43:37 @@ -3054,8 +3054,8 @@ AC_MSG_RESULT(yes) AC_DEFINE(WITH_WINBIND,1,[Whether to build winbind]) - - EXTRA_BIN_PROGS=$EXTRA_BIN_PROGS bin/wbinfo$(EXEEXT) - - EXTRA_SBIN_PROGS=$EXTRA_SBIN_PROGS bin/winbindd$(EXEEXT) + EXTRA_BIN_PROGS=$EXTRA_BIN_PROGS bin/wbinfo$EXEEXT + EXTRA_SBIN_PROGS=$EXTRA_SBIN_PROGS bin/winbindd$EXEEXT if test x$BLDSHARED= xtrue; then SHLIB_PROGS=$SHLIB_PROGS nsswitch/libnss_winbind.so if test x$with_pam= xÿes; then Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE97y4QOmSXH9Mhhs8RAomsAKCQ3xR+vezghJkmK21n9YRAZNUHHgCaApda 4LzIdUvzupIdYJaG/ga6k8Q= =zaJP -END PGP SIGNATURE-
Re: CVS update: samba/source/nmbd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could this possibly fix our problems with joining a domain from W2kSP3 without an explicit realm set? It should... Sorry, doesn't really. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE972SgOmSXH9Mhhs8RAsxXAJ9pT/wwezdgZlo3XI8kcI69BFecSgCfcaAf nFwMwp+l7KDSZjeNxy3Jk8A= =GAJ6 -END PGP SIGNATURE-
Re: CVS update: samba/source/passdb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Make smbpasswd use the group mapping, and fix spelling in ldapsam. Ouch... Thanks! Did I say I did compile this? Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE90CE9OmSXH9Mhhs8RAqMgAJoCD18KsBJttu+Q1GpsOK/SmDKSxwCcCA4t 1++vZDEUoCWskgMiaqCfFGs= =73p8 -END PGP SIGNATURE-
Re: [Samba] 2.2.6 and printer questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you could get around the EULA, then you could package preinitialized drivers and write the information to smbd's tdbs. We have support for storing driver initialization data already. Have you heard that you can get CUPS printer drivers exactly for that from cups.org? If they are good drivers, this could be very interesting. Sounds interesting. Hmmmwish I could read German :-) Part of that site is translated :-) Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE9xieXOmSXH9Mhhs8RAkMvAJ9sigDXJi9n2njyO2+0EVsFnDNkXACeOqz3 G1Ta4CGXvmhc2ZUp8Nff7fg= =zlGF -END PGP SIGNATURE- -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: Comparing SAMBA_3_0 to HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've merged the things I could reasonably be blamed for, plus volker's passdb changes. Thanks for that! I'm currently *very* busy with courses etc, so I don't really have time to work on Samba. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE9xCdBOmSXH9Mhhs8RAm8wAJ9y8JA4RuU8Zm/9BhR8PmV2548nFgCfcyzK X3ou+9dpRUAceQVG/zma+Rs= =QVz0 -END PGP SIGNATURE-
Re: Fixed: OpLocks caused the corruptions/slowness (Was: How Samba let us down)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clients commonly ignore oplock breaks because of network problems (borderline hubs etc.). Many people are suffering from network hardware that performs adequately in light use situations and fails under heavy load. I myself have ended up junking hubs with this problem. Just my 2 cents: I recently had a case where the log.smbd looked like this. Oplock break failures. The customer told me again and again that he does not have any hardware problem. So I went to the site, and he was right. It was a problem with nss_ldap. One smbd opened a file with oplocks. It then had to do something different, calling nss_ldap. nss_ldap then went to sleep, ignoring *all* signals except -9. nss_ldap would not come back. So the oplock break request never made it to the smbd that held the file open. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE9wjsjOmSXH9Mhhs8RAo2GAJ9j5tuwykka3ielhsSgh0ef0koWtACeLnzR 2j20v7sbKT9qa/IURa4pgBE= =Ygp1 -END PGP SIGNATURE-
W2k joins to Samba-HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Here I'm currently playing around with W2k joins to samba-head of yesterday. I have the following phenomena: Join with 'use spnego = yes' works. For W2ksp3 you have to explicitly set a realm. But then you obviously put the Workstation into something like AD-client-mode. If you leave the domain to a workgroup then, it gives the typical error msg that it can not disable the computer account, please talk to your sysadmin. This mode has the problem though that you can not view the domain users in the local management tool to give specific domain users local admin privs. Join with 'use spnego = no' works as well, but then the login later on does not work. Samba says ok to the auth2 request, but the W2k workstation says the computer account does not exist or is invalid. Then saying 'use spnego = yes' enables login AND viewing domain users in the local management tool. Is there any registry-key to enable loggin in without spnego? signseal is off... Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE9wmiLOmSXH9Mhhs8RAmwPAJ4oiKlYq9eptwxZmYWwwuYOI+hkhACgkIMs N7Nh+4U4bgqbGfMWX6Wo9QY= =IQjn -END PGP SIGNATURE-
Re: [PATCH] rid allocator in passdb backend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It would be nice to update the samba.schema only once, so we should now also add the account policy values, etc ... to sambaDomainInfo (all stuff we'll later use for the SAM system) Also add sambaGroup now, would be nice.(with the stuff we'll later use) And changing a few attributes from ascii-string to directory-string, so that we can support utf-8 strings. Has anybody already a new SAM LDAP schema? Don't get me wrong, I'm honestly interested. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9r7t/ZeeQha3jd9gRArFSAJ9pmx3jAuW2U4YNRdGYC5MJxWkvSQCcDokX zP5yTOnkp4Y3Qjocm6QHYg8= =wNqQ -END PGP SIGNATURE-
Re: [PATCH] rid allocator in passdb backend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again! This patch puts a RID allocator into the passdb backend. The outside interface are two calls. I forgot one thing: This patch does not yet handle the case where we already have a sambaDomainInfo entry, but no rid attribute. I do not know how you can make sure that you do not end up with to rid attributes. Does anybody know how to do this? Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9rwPqZeeQha3jd9gRAgwUAJ0Xg4Ie7/lpmyzycQHOJX6RPRampACdHLcP AJ1J4CSR8OGLq2WAAa0AdDI= =7RSP -END PGP SIGNATURE-
Re: Commit my stuff to 3.0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, we need a simple solution, but I'm not sure there is one... Seeing all these Problems I am now not sure if removing all the dependencies on algorithmic mapping is a good idea. I'm currently looking at the code from a different perspective: All this mess came up for the vampire stuff. So, why not treat these RIDs as the exception, and really go for the algorithmic mapping as the rule. I know, I have argued very strongly against that, but it might only have been because I did not see all the consequences. The code probably would have to be cleaned up, but it might simplify a lot. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9qmykZeeQha3jd9gRAhsEAJ9qTOJb8hXCeLU5ETZr7ECHSXV2yACfVUbg 7jYK7Dp+NEsxeBCnX+G7Anc= =1hTz -END PGP SIGNATURE-
Re: auth.c Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Also, I wanted to be sure we always got correct uid-sid and sid-uid mapping for the guest user. I wanted an NT ACL to be able to include this 'well known' user, and have it behave as expected. While *most* cases inside Samba now use just the NT_TOEKN generated at login time, we still make one up from uid/gid/groups in a number of cases. I wanted to ensure as much as possible that the 2 tokens are identical. Do you have a pattern to look for? I would like to look at those cases. The rest of unixsam was added becouse I wanted it to be able to be removed :-). That is, if the admin had all users in LDAP, I wanted the admin to be able to remove it from the smb.conf, and remove all the 'implicit' algorithmic mappings and magic unix mappings. We are not quite there yet, unfortunetly - there are a large number of corner cases here. These need to be resolved. For the passdb and for the new SAM stuff as well ;-)) Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9qSAsZeeQha3jd9gRAntQAJ9hL0eFn11pFuIpKMyWdbMRxj15/ACfXQJJ nr+B9XMlGmYeg6yKjzV2c/I= =ev2W -END PGP SIGNATURE-
Re: Commit my stuff to 3.0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I know why 'only algorithmic' mapping is a pain - we can't do migration from NT, but why is adding algorithmic RIDs a problem here? (Other than asthetics) I do not really like the idea of mixing two approaches. Ok, you can make reasonably sure that both do not clash with a high enough algorithmic rid base. Hmm. From a functionality point of view, it is mainly asthetic. And fearing that we might miss corner cases. Not giving anything back from pdb_getsampwnam when the user is not in SAM is much more obvious than a user magically popping up. But yes, this is one of the ugliest parts of the unixsam approach. It also has implications for the 'add computer to domain' priviage. Basicly, we have to decided if unix users not in a SAM backend are in the domain. I would vote for 'NO'. The problem is that we currently allocate them a SID as if they are members of the domain. And we need to be able to preserve that allocation, even if we add them to smbpasswd - sombody could have aimed an NT backup tool at us, and we gave the OLD SID as a the owner, and when we 'restore' it's 'gone'. I would not see this as a problem. The same happens if you delete a user between backup and restore. Messing with the user database kills backups even under unix most of the time. Or we have a domain user, who owns files on a workstation. This user's smbpasswd record is deleted - should we no longer map that SID to the users unix name? (Quite possibly the answer is yes). Should users not in smbpasswd be mapped uid-sid-name at all? Currently we do, and some NAS products use this behaviour. My solution for this is mapping users not in the 'rich' pdb backend to S-1-5-33-uid (no typo!). This is the newly created 'local unix auth'. lookupsid should return 'not mapped', as NT4 would after that look up 'local unix auth'#1c... W2k shows the SID in plain text, NT4 shows 'local unix auth\account unknown' We have many of these problems already, but they get worse when allocated RIDs are the norm, rather then the exception. Perhaps we should move SID-uid and uid-SID stuff into a seperate module? This was somthing we were looking at for the 'new SAM', but maybe we need it sooner. (It is not dependent on the rest of the work). I remember the word SURS ;-) I think this would not help. We will never be perfect NT, we will always have rough edges. But at least if the behaviour is known and documented, I would be happy. I need to *explain* that stuff to people sitting in courses. For this simplicity is really important. I think this is one of the 'not like NT, but what admin expects' things - and I agree. Possible make groups 100 'aliases' by default, but that's minor. Ok, thanks. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9qSSdZeeQha3jd9gRAkK8AJwJAmUZEeOo1k4u9jvQJMtLXovWsQCfVA9u 0G+zQs04cxXKep1s086xxxU= =D7mS -END PGP SIGNATURE-
Re: Commit my stuff to 3.0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Discussion moved to samba-technical. Instead of just doing a pdb_getsampwnam() on the name from pass struct, I would prefer that we instead change the callers. Most of the callers can be changed to do the pdb_getsampwnam() instead of Get_Pwnam(), now that we have unixsam giving us access to all users. (This is why we didn't do this before). To be honest I would like to get rid of the necessity of unixsam for encrypted passwords. One case where this breaks: You want a workstation to join your domain. You do not want to use 'add user script', so you add the wks account to /etc/passwd. _api_samr_create_user says user exists, and after that set_userinfo creates the account in passdb. And boom, you again have algorithmic mapping in your rich passdb backend. I am not sure if metze's new passdb code covers this case, but there are so many cases like this where pdb_getsampwnam succeeding just from unixsam is not transparent enough for the caller. Given that we need passdb and groups in 3.0, I woud support merging it in there. In particualar this should simplify greatly the 'name - sid' and 'sid - name' code. (Add calls for these to the interface). If I started to rewrite the group mapping API, I would like to remove the enumgroups call. This is just too ugly for large numbers of groups. And people *will* use lots of groups, especially as we do not have support for nested groups. And when automagically creating group mappings, I would like to create them as domain groups and not as aliases. I think this is what users would expect. It also removes the annoying messages that NT does not like aliases as a user's primary group. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9qE5PZeeQha3jd9gRAgYtAJ9WxUJ3Wzc9IVasZvuQi1vFl413qACcCAhy O+0OO6J8WTqpOxHR0F+oXm8= =+CCE -END PGP SIGNATURE-
Re: winbindd and missing 0x1c role on UNICAST_SUBNET
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I do have one question, though. If a samba PDC has multiple interfaces, would you want the PDC role registered with the PDC's ip on each interface? I think that would be accomplished if your insert_permanent_name_into_unicast were moved inside the subnet list loop, and called for each subnet instead of FIRST_SUBNET. Or maybe I don't understand how the unicast subnet works? Jerry and Jeremy will take care of that problem. I don't really understand nmbd well enough. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9ovX3ZeeQha3jd9gRApbkAJ4tRF3zWiShlsOaTuEDk/BZgrrORwCfZeoJ 7XNZqZKSeE3aAIDjjh8jxHE= =zzbg -END PGP SIGNATURE-
Re: A RID allocator and its consequences
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, the really nasty bit about this is the implict mapping of existing unix accounts to rids. I went to a lot of effor to try and get rid of it - but the best I could do was hide it under a pile of interfaces and pretend it wasn't there ;-) If you use smbpasswd, naturally, you get 'algorithmic' rids. Fine, you probably won't be using smbpasswd for this game anyway. The problem is that any unix user must also have a RID. This is becouse at any time, a user might try and get the security descriptor of a file. First of all: My patch is absolutely experimental stuff, not yet meant seriously. The right way would have been to remove the group rid from SAM_ACCOUNT. But this would have changed the interface which I did not want to touch in the first rounnd. smbpasswd is the one where we get algorithmic mapping. I would like to see the algorithms in pdb_smbpasswd if that is possible. Or share it with nisplus (I still have to look at that one.). This however means that pdb_smbpasswd needs some knowlege of groups to be able to at least hand out a group rid upon demand. Hmm. Where does that lead? ;-) The next problem is that we don't like reusing RIDs - so if that rid was ever available 'implicitly' then we should not use it. Also, a user 'upgraded' from /etc/passwd should keep the same RID. This is the reasoning for the crazy stuff in unixsam. (I'm still undecided if it's very neat or an ugly hack...). What crazy stuff do you mean? unixsam_update_sam_account? However, there is an 'out'. If you never specify 'unixsam', and always import users, setting a rid when you add them (currently smbpasswd uses the algorithm or their unixsam upgrade), then this will work. But if sombody asks for a security descriptor on a file, and we don't know the mapping for that owner, then it will fail. BTW, using 'hide unreadable' counts as asking for the mapping, as I found out recently... For non-smbpasswd backends can't we take the same route as with get_group_from_gid: Create pdb entries on the fly? Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9lAGlZeeQha3jd9gRAk3lAJ0X56cAzLG4XQrgSjmsYelw73TavQCbBM2/ 0tt7lf490iSA6ZQN3MU1vXo= =9VQF -END PGP SIGNATURE-
Re: A RID allocator and its consequences
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 pdb_smbpasswd and pdb_unixsam both use the code in passdb.c (pdb_fill_sam_pw()) to construct their SAM_ACCOUNT, and to do uid-sid mapping. In fact, becouse of this, smbpasswd already uses the gid code to determine the primary group RID on the fly. My thought was that pdb_smbpasswd has to tell get_group_from_gid that in this particular case we need the algorithmic mapping. The RID allocator will interfere with the algorithmic mapping for uids for smbpasswd. What crazy stuff do you mean? unixsam_update_sam_account? That certainly sounds familure. And I'm still looking at the consequences of that hack. I'll tell you what I think later :-) As long as we have never made an implicit mapping between that uid and RID, then it's fine. That's what I'm trying to hammer out currently. One of the ideas with the new SAM stuff is that we always control this mapping - it's the autoalgoirthmic stuff that kills us here... Diggin through the muddy waters of fallback_pdb_* ... The only other trick is 'outside modification'. When people put this stuff into LDAP, they often like to modify it directly. This may be 'a bad thing', but it's also somthing we must at least tolerate. (I certainly do it at my site). Therefore having the max rid stuff in LDAP might be benifitial. Yes. As I said, this was code of about 3 hours. But following Eric Raymond: Release early, release often. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9lAsYZeeQha3jd9gRAox4AJ0eDQw8c1S05kUclULqA1O3WQ34aACdEAht kPkFtryKEpHxUu+x5u5BBsI= =nBSk -END PGP SIGNATURE-
A RID allocator and its consequences
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
This is a surprisingly little (compiled, but not tested) patch that
mainly should do the following:
Implement a rid allocator in secrets.tdb. This might not be the right
place to do it, but as we are one-domain with passdb, RID allocation
is a global thing.
Second, in get_group_from_gid it initializes a new group mapping as an
alias on the fly. So if the gid exists it should basically not fail
anymore.
Third, as a consequence of get_group_from_gid, most of the calls to
pdb_gid_to_group_rid are gone. There's two left in passdb.c which I
don't really understand. Maybe it's too late now. The remaining one is
in pdb_nisplus which I will not touch for now.
This is only an interim step I think, the next step would be to remove
the group_sid from SAM_ACCOUNT completely, as we can now always get a
SID for a gid.
Volker
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370
iD8DBQE9k3PwZeeQha3jd9gRAs4qAJ49Ua2+Qx+T7Zvd8mNdCAXunOcv7ACeOCQe
i2OZ34EVYmXfLS8hzTUoidc=
=BVZQ
-END PGP SIGNATURE-
diff -ur samba/cvs/head/samba/source/Makefile.in head/source/Makefile.in
--- samba/cvs/head/samba/source/Makefile.in Thu Sep 26 14:13:29 2002
+++ head/source/Makefile.in Thu Sep 26 17:37:42 2002
-429,8 +429,9
$(UBIQX_OBJ) $(LIB_OBJ)
SMBCACLS_OBJ = utils/smbcacls.o $(LOCKING_OBJ) $(LIBSMB_OBJ) $(PARAM_OBJ) \
- $(UBIQX_OBJ) $(LIB_OBJ) $(RPC_PARSE_OBJ) $(PASSDB_GET_SET_OBJ) \
-$(LIBMSRPC_OBJ)
+ $(UBIQX_OBJ) $(LIB_OBJ) $(RPC_PARSE_OBJ) $(SECRETS_OBJ) \
+$(LIBMSRPC_OBJ) $(PASSDB_OBJ) $(GROUPDB_OBJ)
+
TALLOCTORT_OBJ = lib/talloctort.o $(LIB_OBJ) $(PARAM_OBJ) $(UBIQX_OBJ)
-494,7 +495,7
nsswitch/winbindd_dual.o
WINBINDD_OBJ = \
- $(WINBINDD_OBJ1) $(PASSDB_GET_SET_OBJ) \
+ $(WINBINDD_OBJ1) $(PASSDB_OBJ) $(GROUPDB_OBJ) \
$(LIBNMB_OBJ) $(PARAM_OBJ) $(UBIQX_OBJ) $(LIB_OBJ) \
$(LIBSMB_OBJ) $(LIBMSRPC_OBJ) $(RPC_PARSE_OBJ) \
$(PROFILE_OBJ) $(UNIGRP_OBJ) \
diff -ur samba/cvs/head/samba/source/groupdb/mapping.c head/source/groupdb/mapping.c
--- samba/cvs/head/samba/source/groupdb/mapping.c Mon Sep 23 18:34:17 2002
+++ head/source/groupdb/mapping.c Thu Sep 26 22:39:00 2002
-1040,14 +1040,13
return True;
}
-
-
/
Returns a GROUP_MAP struct based on the gid.
/
BOOL get_group_from_gid(gid_t gid, GROUP_MAP *map, BOOL with_priv)
{
struct group *grp;
+ uint32 rid;
if(!init_group_mapping()) {
DEBUG(0,(failed to initialize group mapping));
-1057,24 +1056,46
if ( (grp=getgrgid(gid)) == NULL)
return False;
- /*
-* make a group map from scratch if doesn't exist.
-*/
- if (!get_group_map_from_gid(gid, map, with_priv)) {
- map-gid=gid;
- map-sid_name_use=SID_NAME_ALIAS;
- map-systemaccount=PR_ACCESS_FROM_NETWORK;
- init_privilege(map-priv_set);
-
- /* interim solution until we have a last RID allocated */
+ if (get_group_map_from_gid(gid, map, with_priv))
+ return True;
- sid_copy(map-sid, get_global_sam_sid());
- sid_append_rid(map-sid, pdb_gid_to_group_rid(gid));
+ /* There's no mapping, try to create one on the fly. */
- fstrcpy(map-nt_name, grp-gr_name);
- fstrcpy(map-comment, Local Unix Group);
+ if ((rid = secrets_allocate_rid()) != 0) {
+ DOM_SID sid;
+ fstring string_sid;
+ PRIVILEGE_SET priv_set;
+
+ sid_copy(sid, get_global_sam_sid());
+ sid_append_rid(sid, rid);
+ sid_to_string(string_sid, sid);
+ init_privilege(priv_set);
+
+ if (add_initial_entry(gid, string_sid, SID_NAME_ALIAS,
+ grp-gr_name, Local Unix Group,
+ priv_set, PR_ACCESS_FROM_NETWORK)) {
+ if (get_group_map_from_gid(gid, map, with_priv))
+ return True;
+ }
+ DEBUG(0, (Weird! Did not find the group map just created\n));
}
-
+
+ /* Fake a group. This is just a bad hack, as
+ the RID will clash with a mapped group. */
+
+ DEBUG(0, (Faking a group mapping\n));
+
+ map-gid=gid;
+ map-sid_name_use=SID_NAME_ALIAS;
+ map-systemaccount=PR_ACCESS_FROM_NETWORK;
+ init_privilege(map-priv_set);
+
+ sid_copy(map-sid, get_global_sam_sid());
+ sid_append_rid(map-sid, pdb_gid_to_group_rid(gid));
+
+
Re: Bug in HEAD: srv_samr_nt.c and smbgroupedit assume algorithmic RIDs.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As you work into this area, you will see why we decided on the 'start over'... My concern is that we will not be able to finish that work in any reasonable time frame. I would like to see 3.0 released. I completely agree that a redesign is desirable, but I would like to have a decently working PDC with 3.0. Otherwise we might simply want to dump 'net rpc vampire' completely. I would then take it out again so that people don't even expect something like this to work. Currently there is no consensus upon how to replicate group mapping information to a Samba BDC. We should drop that support as well. Simply remove the 'server role BDC'. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9ka6/ZeeQha3jd9gRAmX0AJ9JelfYh5qSIDTcLVDlyR6SdJOTlACaAkJz d12SzfNtoRoth/2XXwRnmx4= =dsaO -END PGP SIGNATURE-
Re: SID changes for a PDC when you change its name ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you change the server name of a PDC, Samba generates a new machine SID because of an incorrect test in pdb_generate_sam_sid. I stumbled across that one as well. Jerry had some reason for it, which I don't remember. Secondly, it would be nice if there was a command like 'net rpc setlocalsid S-1-5-21-x-y-z' that allowed you to set the SID in the secrets database when you need to. No rpc involved -- what about 'net setlocalsid S-1-5-21-x-y-z'? It's trivial. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9jsApZeeQha3jd9gRAqSmAJ48Ey0YgVWKEzaiIoyMCC8zclTR9ACePnD1 +Xhs9Fd2CHG209iYAXw0UBQ= =OeiC -END PGP SIGNATURE-
Obeying primary group in /etc/passwd ?
Hi!
What do you think about the following patch? More consistent would be
to remove the group_sid from SAM_ACCOUNT completely, as we can always
get this from /etc/passwd.
Volker
Index: pdb_get_set.c
===
RCS file: /data/cvs/samba/source/passdb/pdb_get_set.c,v
retrieving revision 1.17
diff -u -r1.17 pdb_get_set.c
--- pdb_get_set.c 24 Jul 2002 05:04:18 - 1.17
+++ pdb_get_set.c 23 Sep 2002 13:43:09 -
-166,11 +166,24
const DOM_SID *pdb_get_group_sid(const SAM_ACCOUNT *sampass)
{
- if (sampass)
- return sampass-private.group_sid;
- else
+ struct passwd *pwd;
+ static GROUP_MAP map;
+
+ if (!sampass)
return (NULL);
-}
+
+ /* If the user's unix primary group is mapped to a NT SID, use
+ that. Otherwise use the pdb-stored SID. Unix is still boss
+ here :-) */
+
+ if ((pwd = getpwuid(sampass-private.uid)) == NULL)
+ return sampass-private.group_sid;
+
+ if (!get_group_map_from_gid(pwd-pw_gid, map, False))
+ return sampass-private.group_sid;
+
+ return map.sid;
+}
/**
* Get flags showing what is initalised in the SAM_ACCOUNT
Re: 2.2.5 crashes in cli_errstr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As you requested: Sorry to bother you again, but would a tcpdump be possible: tcpdump -i eth0 -n -s 1600 -w pdc.out host 172.21.63.142. The logfile is quite weird. First you can connect: [2002/08/29 15:11:42, 3, pid=12863] lib/util_sock.c:open_socket_out(845) Connecting to 172.21.63.142 at port 139 [2002/08/29 15:11:42, 5, pid=12863] lib/util_sock.c:print_socket_options(111) Then you get some strange packet, I'd be interested in what that is: lib/util_sock.c:read_smb_length_return_keepalive(559) got smb length of 1 [2002/08/29 15:11:42, 5, pid=12863] lib/util.c:show_msg(275) size=1 smb_com=0x0 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=0 smb_flg2=0 [2002/08/29 15:11:42, 5, pid=12863] lib/util.c:show_msg(281) smb_tid=0 smb_pid=0 smb_uid=0 smb_mid=0 smt_wct=0 [2002/08/29 15:11:42, 5, pid=12863] lib/util.c:show_msg(291) smb_bcc=0 And immediately after that you get timeouts connecting: [2002/08/29 15:11:42, 3, pid=12863] lib/util_sock.c:open_socket_out(845) Connecting to 172.21.63.142 at port 445 [2002/08/29 15:11:42, 1, pid=12863] lib/util_sock.c:open_socket_out(860) timeout connecting to 172.21.63.142:445 [2002/08/29 15:11:42, 3, pid=12863] lib/util_sock.c:open_socket_out(845) Connecting to 172.21.63.142 at port 139 [2002/08/29 15:11:42, 1, pid=12863] lib/util_sock.c:open_socket_out(860) timeout connecting to 172.21.63.142:139 [2002/08/29 15:11:42, 1, pid=12863] libsmb/cliconnect.c:cli_connect(782) Error connecting to 172.21.63.142 (Operation now in progress) What the hell is happening here??? Samba should definitely not coredump, but something a bit weird is going on. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9b0MyZeeQha3jd9gRAiUDAJ9YOEpJYTw+UVxn1+7/VhfP9eCgewCfSldz 14jhrZYYoXYMnuUqAuteuuA= =kN8u -END PGP SIGNATURE-
Re: 2.2.5 crashes in cli_errstr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wrong. When setting a drop rule it just gets stuck. And after removing the drop rule, smbd does not recover. The smbd panic occurs when the domain controller is rebooted. In this case smbd does not recover, too. Today I added a route to nowhere for the DC, some clients connected and got no authentication. Even after removing the misleading route, smbd gets stuck after resolving the name (see log at 16:50). And at 17:08 I rebooted the DC. Here are the 2.2.4 logs: I really can't see what's going wrong. I can still not reproduce the crash. Could you provide *exact* steps (kernel version, routing table, ip addresses, etc) to reproduce this with latest 2.2 CVS code? To get the latest 2.2 cvs, see http://www.samba.org/samba/cvs.html. Thanks, Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9bf6sZeeQha3jd9gRAjhUAJ91PcKi2T1LZgBKbfnTfD95oDBR4QCdG+Zm joLSGnfl76/plRs5icKmff0= =1CeU -END PGP SIGNATURE-
[Samba] Re: Domain SID for BDC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 btw...i setup a Samba PDC using LDAP by copying the secrets.tdb file and the setting the domain SID (using smbpasswd). Worked fine. Did not need to reent the ldap admin pw again. Yes, worked for me as well. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Fingerprint available: phone +49 551 370 iD8DBQE9BJqgZeeQha3jd9gRAlW5AJ9nHfufvvTiywgkI4eXuHHyEPh3GwCeJ2mP pgsMvM8PC2KrOUq/KWOPJd4= =f1Nn -END PGP SIGNATURE- -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: Domain SID for BDC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 btw...i setup a Samba PDC using LDAP by copying the secrets.tdb file and the setting the domain SID (using smbpasswd). Worked fine. Did not need to reent the ldap admin pw again. Yes, worked for me as well. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Fingerprint available: phone +49 551 370 iD8DBQE9BJqgZeeQha3jd9gRAlW5AJ9nHfufvvTiywgkI4eXuHHyEPh3GwCeJ2mP pgsMvM8PC2KrOUq/KWOPJd4= =f1Nn -END PGP SIGNATURE-
[Samba] Re: Domain SID for BDC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just added a -S switch to smbpasswd in SAMBA_2_2 to suck the sid from a DC. My tests show up ok. Can you test this? I'll update the man page shortly. For me it worked well, thanks! I'm using it in about an hour in my Linuxtag talk ;-) Thanks, Volker (fingers crossed) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Fingerprint available: phone +49 551 370 iD8DBQE9AbHWZeeQha3jd9gRAis4AJ0XTcugnRdbfTRgCVxI1JuGi19w6wCeIBFH IUIUEgTXaGPb4B9lWikOe5Q= =oNGH -END PGP SIGNATURE- -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Re: Domain SID for BDC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just added a -S switch to smbpasswd in SAMBA_2_2 to suck the sid from a DC. My tests show up ok. Can you test this? I'll update the man page shortly. For me it worked well, thanks! I'm using it in about an hour in my Linuxtag talk ;-) Thanks, Volker (fingers crossed) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Fingerprint available: phone +49 551 370 iD8DBQE9AbHWZeeQha3jd9gRAis4AJ0XTcugnRdbfTRgCVxI1JuGi19w6wCeIBFH IUIUEgTXaGPb4B9lWikOe5Q= =oNGH -END PGP SIGNATURE-
corrupt tdb?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Someone came to me with the following log message. To me it looks like a corrupt tdb. The system is running Linux 2.2.19 with adaptec RAID (dpt_io driver), LVM and the tdb's on ext2. The rest of the file system is reiser. Samba is 2.2.3a. I don't remember tdb corruption fixes towards 2.2.4. Or did I miss any? Volker [2002/05/30 15:47:41, 0, pid=4508] tdb/tdbutil.c:tdb_log(475) tdb(/sambalocks/PRR0226/sessionid.tdb): tdb_oob len 976499000 beyond eof at 32768 [2002/05/30 15:47:41, 0, pid=4066] tdb/tdbutil.c:tdb_log(475) [2002/05/30 15:47:41, 0, pid=4508] tdb/tdbutil.c:tdb_log(475) tdb(/sambalocks/PRR0226/sessionid.tdb): tdb_oob len 808465011 beyond eof at 32768 [2002/05/30 15:47:41, 1, pid=4508] smbd/session.c:session_claim(88) session_claim: out of session IDs (max is 3000) tdb(/sambalocks/PRR0226/sessionid.tdb): tdb_oob len 1768185734 beyond eof at 32768 [2002/05/30 15:47:41, 1, pid=4508] smbd/password.c:register_vuid(337) Failed to claim session for vuid=100 [2002/05/30 15:47:41, 0, pid=4066] tdb/tdbutil.c:tdb_log(475) tdb(/sambalocks/PRR0226/sessionid.tdb): tdb_oob len 808465011 beyond eof at 32768 [2002/05/30 15:47:41, 0, pid=4066] tdb/tdbutil.c:tdb_log(475) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Fingerprint available: phone +49 551 370 iD8DBQE892yEZeeQha3jd9gRAmHPAJ46N/5D8NkiCnvuQXgcf1l4TavMLwCfR16L r71eUQDbBIi7k6ERQR1/a0U= =1Ajq -END PGP SIGNATURE-
