Re: A RID allocator and its consequences
On Fri, Sep 27, 2002 at 07:36:25AM +0200, Volker Lendecke wrote: > > It is the wrong place to do it. If some data should only be accessible > > by root then it should live in secrets.tdb otherwise it should go > > somewhere else. > > I know. This is just experimental code playing with the thought how far you can > take the existing passdb interface. Take out the domain SIDs as well? Yup. Not sure where to put it though - notsecret.tdb? (-: Tim.
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-
Re: A RID allocator and its consequences
[EMAIL PROTECTED] wrote: > > -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? ;-) 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. Teaching the other backends to do the same - or deleting the primary group sid is quite reasonable. > > 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? That certainly sounds familure. > > 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? As long as we have never made an implicit mapping between that uid and RID, then it's fine. 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... 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. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
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
[EMAIL PROTECTED] wrote: > > -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. 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. 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...). 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... Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: A RID allocator and its consequences
Volker Lendecke wrote: > > On Fri, Sep 27, 2002 at 07:44:36AM +1000, Tim Potter wrote: > > It is the wrong place to do it. If some data should only be accessible > > by root then it should live in secrets.tdb otherwise it should go > > somewhere else. > > I know. This is just experimental code playing with the thought how far you can > take the existing passdb interface. Take out the domain SIDs as well? yes, domain sids do belong elsewhere. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: A RID allocator and its consequences
On Fri, Sep 27, 2002 at 07:44:36AM +1000, Tim Potter wrote: > It is the wrong place to do it. If some data should only be accessible > by root then it should live in secrets.tdb otherwise it should go > somewhere else. I know. This is just experimental code playing with the thought how far you can take the existing passdb interface. Take out the domain SIDs as well? Volker msg03299/pgp0.pgp Description: PGP signature
Re: A RID allocator and its consequences
On Thu, Sep 26, 2002 at 10:59:25PM +0200, [EMAIL PROTECTED] wrote: > 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. It is the wrong place to do it. If some data should only be accessible by root then it should live in secrets.tdb otherwise it should go somewhere else. Tim.
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_app
