Re: [PATCH] sam backend parameter
[EMAIL PROTECTED] wrote:
On Thu, Oct 03, 2002 at 04:06:37PM +1000, Andrew Bartlett wrote:
The use of multiple backends in passdb has acknowledged issues, and I'm
not particularly fussed if you feel it should not ship with this
functionality enabled. However, please do note that this *is* being
used at present, and cannot be 'just removed'. (We map our non-passdb
users into the system via this method). Volker has some solutions to
this issue however, which look very neat. I'll need to check if they
actually catch it all the cases.
Well it's not being used really, as it's not in a production
release. We don't make guarentees until it gets into a production
release. What non-passdb users are being mapped into the system
via this method ? Surely as a PDC we need passdb entries for every
user we're exporting ?
I mean it's being used by code.
The problem is mainly on the fileserver: For the DC side of things,
every user is in the SAM, or they can't really do much. But on the
fileserver side, we have the problem that a user may select to view the
Owner or the ACL entries of a file.
This file may have a completely arbitrary owner.
- Winbind user? Fine. (we simply lookup the uid-sid with wibnind, and
we simply proxy requests for the name-sid/sid-name to the DC)
- passdb user? Again, OK.
In 2.2, we just used an algorithmic mapping of all such users. Remember
'2*uid+1000'? :-) Names were then looked up in the system get{pw,gr}*
calls
In HEAD, we tried to make this a bit smarter. This may or may not have
been a good thing, because it can be slow. We do getpwuid(uid), then
lookup that name in the passdb. The returned SID is sent to the client.
For names, it's a bit easier, we lookup the SID in passdb then return
the name. The reverse for name-sid. I did it this way to allow for
arbitrary RIDs.
- not in either... Not so pretty:
The tricky bit is users not in passdb. The code that deals with this is
hideous, particularly because we don't have a unified groupdb/passdb,
and mostly because I wanted to support arbitrary RIDs. (Hence one of the
reasons I started trying to rewrite this).
We need to allocate this 'unknown' user or group a RID. We need to
ensure it does not conflict with other users, and that it 'maps back'.
Why? Well, there are system accounts etc, and there are users who
appear in the system via NIS etc. The 2.2 code maps these to
SIDs/Names, and I took this as a requirement that we must do the same in
3.0
The addition of 'unixsam' was designed to put common code together.
Other parts of passdb had to deal with making a SAM entry from a passwd
struct, so I merged the code. I had considered a complete merge with
smbpasswd, but never got that far. Volker has noted a number of areas
in the auth code that could be simplified by exploiting this.
This also assisted in moving our calls to Get_Pwnam() into a very small
number of places. It is very rarely called now.
If required, this code could be split back out again, however we still
have the issue of RID allocation. (the cascading change did not affect
this, it is noted for completeness).
The rids in HEAD are allocated by '2*uid+lp_algorithmic_rid_base()', to
allow the administrator to 'push' the algorithmic space 'out of the
way'. We should look into 'automatic' RID allocation, but I am wary of
inflicting this on all our file-server users.
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: [PATCH] sam backend parameter
On Thu, Oct 03, 2002 at 06:15:01AM +, [EMAIL PROTECTED] wrote about 'Re: [PATCH] sam backend parameter': On Thu, Oct 03, 2002 at 04:06:37PM +1000, Andrew Bartlett wrote: The use of multiple backends in passdb has acknowledged issues, and I'm not particularly fussed if you feel it should not ship with this functionality enabled. However, please do note that this *is* being used at present, and cannot be 'just removed'. (We map our non-passdb users into the system via this method). Volker has some solutions to this issue however, which look very neat. I'll need to check if they actually catch it all the cases. Well it's not being used really, as it's not in a production release. We don't make guarentees until it gets into a production release. What non-passdb users are being mapped into the system via this method ? Surely as a PDC we need passdb entries for every user we're exporting ? See the pdb_unix backend. We currently map users that are only in the system database as well. This means that you can see files owned by certain users that are not mapped in any of the other loaded pdb' . When a sysadmin tries to update the properties of such a user, it is added to the default pdb backend. Jelmer
Re: [PATCH] sam backend parameter
On Thu, 2002-10-03 at 03:01, Andrew Bartlett wrote: Simo Sorce wrote: Plus I have some questions about the current sam interface: - what is all the context thing needed for? I don't like global variables, and this allows us to construct seperate contexts for operations like sam2sam, and testing, without fiddiling with global variables. There's no problem in having global variables, provided they are used correctly. Insisting to not use them in any case just as a preconcept is as wrong as using them too much. It is all a question on how and where you use them. sam2sam operation does not need access checking and interface virtualization, it is an administrative task only anyway, try to put sam2sam above the sam interface instead of making it directly connect to the backends is just a bad idea, it add complexity and potential problems and gain nothing, imho. And sam2 sam is the only case where it could be useful to have 2 backends loaded at the same time. So it is perfectly possible to make it's own init function that load 2 backends into 2 local (to samedit) variables, while still loading the sam backend into a global variable used by the sam interface inside smbd. - what is the handle thing needed for ? Same as the SAM_ACCOUNT in pdb. If it's a SAM_ACCOUNT then call it with it's name. Also I really to not like the private substructure. We are all adult and vaccinated, and must trust each other ability to code and use internal structures properly, trying to say: I do not trust other coders is not a bright move imho, add unneeded complexity, SAM_ACCOUNT structure directly will do so regardless if theres a thing called private or not. Adding this layer only makes the interface a lot more heavier and trickier, make code slower (adds a function call for each parameter to be set into a structure) and the sam interface a lot bigger. Effort should be spent to educate other programmers to use the thing the right way by writing documentation, not by setting artificial barriers. - what is access desired meant to do ? Authorization is a different thing then storage, a backend is a storage! The SAM interface layer is the 'choke point'. If we do not wan't nasty races, then we must reterive things like the security descriptor with the data it applies to. This implies that the ACL checking code must resise either in the SAM backend, or the SAM interface. If we export it above this layer, we *will* get places where we don't check it properly. It must be in the Interface, putting it on the backend is the wrong move for many reasons: - code duplication, you have to implement the access checking into evry backend. - code review, authorization is a critical part of the security in samba, if you have to double check every module to be sure it does things the right way, you simply castrate the potentiality of a loadble module interface, as you put too much responsibility on independent module coders. - consistency every change you need to make to the access checking code, bust be made to any module and will make out of sync any modules not under your control, increasing the module versioning nightmare. - races may be easily solved supporting locks on the backend. - why do we insist to have a thing called unix accounts? It just does not make sense to me. We need real users/groups mapping instead (opposed to created on the fly by winbind based accounts). I'm not sure what you mean here - the current code doesn't even know about unix accounts. They are present in pdb, and I remember at some point of the discussion we had on IRC someone claimed that multiple modules were also a way to solve the unix accounts problem like done in with pdb backends. What Instead I think is that we should not threat unix accounts in any special way, but instead we need to map them to normal users when they are present, if a user do not have a local unix user then it will be created in winbindd, otherwise the uid-SID mapping will be done so that the user is mapped on a unix user. All the mapping should consist ONLY of a SID-[u,g]id mapping imho, and we should discourage using unix groups provided from /etc/group file and use instead winbindd to provide them to the system, but still use them from /etc/group if the administrator want to do so. Simo. -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: [PATCH] sam backend parameter
On Thu, Oct 03, 2002 at 08:34:47PM +1000, Andrew Bartlett wrote about 'Re: [PATCH] sam backend parameter': There is no intention to create a similar backend for the sam. Instead, we do intend to solve this problem in exactly the way you indicate below. There is no intention to provide a 'mulidb' module either. The only way to load more than one module will be to have separate domains. Why? I think having a multidb module would be the perfect solution for when one has multiple backends - it doesn't clutter the interface and provides those people who need it support for multiple backends. Jelmer
Re: [PATCH] sam backend parameter
On Thu, 2002-10-03 at 07:22, Jelmer Vernooij wrote:
On Thu, Oct 03, 2002 at 12:16:53AM +0200, Simo Sorce wrote about 'Re: [PATCH] sam
backend parameter':
yes a thing I'm not sure has ever been a good idea.
to be able to have sam2sam that is really read a backend + store all
info into another backend we may take several ways.
We never need the 2 backend to be loaded at the same time to do the
operation, we may easily read all the accounts chnage the backend and
store them into the new one, or simply make custom code to load 2
different backends, and use theyr calls.
It's easy to have 2 structures calle backend1 and backend2 that holds
the functon pointers for 2 backends.
Al the context things always seemed to me overcomplicated even for
multiple backend code.
the context stuff has been in passdb since the beginning and is not
at all used for multiple backends - multiple backends are achieved by
having multiple 'methods' structs in one context.
Next to that, a 'multidb' backend will have to use multiple contexts.
We don't want to spoil global name space with the variables
sam_context contains.
If we are removing multiple domain support, we could remove
sam_methods perhaps and move all the functions in sam_methods to
sam_context, but sam_context definitely has to stay...
Jelmer
Ok, I looked back at what do currently context contain in passdb (see
below Appendix A).
It is simply a structure containing the function pointers of the
backend.
Of course it need to stay here, it only have a really bad name that make
you think of a totally different thing :-)
I think pdb_functions could have been a better name (no not methods, we
are programmin in C not in Java ;-)
Simo.
Appendix A:
typedef struct pdb_context
{
struct pdb_methods *pdb_methods;
struct pdb_methods *pwent_methods;
/* These functions are wrappers for the functions listed above.
They may do extra things like re-reading a SAM_ACCOUNT on update */
BOOL (*pdb_setsampwent)(struct pdb_context *, BOOL update);
void (*pdb_endsampwent)(struct pdb_context *);
BOOL (*pdb_getsampwent)(struct pdb_context *, SAM_ACCOUNT *user);
BOOL (*pdb_getsampwnam)(struct pdb_context *, SAM_ACCOUNT *sam_acct,
const char *username);
BOOL (*pdb_getsampwsid)(struct pdb_context *, SAM_ACCOUNT *sam_acct,
const DOM_SID *sid);
BOOL (*pdb_add_sam_account)(struct pdb_context *, SAM_ACCOUNT
*sampass);
BOOL (*pdb_update_sam_account)(struct pdb_context *, SAM_ACCOUNT
*sampass);
BOOL (*pdb_delete_sam_account)(struct pdb_context *, SAM_ACCOUNT
*username);
void (*free_fn)(struct pdb_context **);
TALLOC_CTX *mem_ctx;
} PDB_CONTEXT;
--
Simo Sorce - [EMAIL PROTECTED]
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] sam backend parameter
On Thu, 2002-10-03 at 08:06, Andrew Bartlett wrote: [EMAIL PROTECTED] wrote: Let just remove the multi-domain stuff for now and try and get 3.0 in a shippable state. The 'new SAM' stuff is not being proposed for 3.0! Certainly not yet, we have a *lot* of work to do, before it gets there! Also, *please* don't confuse that with the multi-backend stuff. That has a very different purpose, and was not included in the new SAM design for exactly the reasons people don't want it in passdb. The use of multiple backends in passdb has acknowledged issues, and I'm not particularly fussed if you feel it should not ship with this functionality enabled. However, please do note that this *is* being used at present, and cannot be 'just removed'. (We map our non-passdb users into the system via this method). Volker has some solutions to this issue however, which look very neat. I'll need to check if they actually catch it all the cases. So let me understand: you say sam will not be in 3.0 you see currently passdb has been made so that nobody like it and is not good but you also say we should not end up using a correct solution because you want to maintain the status quo? We have to fix passdb or sam, just let decide on which one we should work on or go for a third way. Simo. -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: [PATCH] sam backend parameter
On Thu, 2002-10-03 at 08:47, Andrew Bartlett wrote: [EMAIL PROTECTED] wrote: Well it's not being used really, as it's not in a production release. We don't make guarentees until it gets into a production release. What non-passdb users are being mapped into the system via this method ? Surely as a PDC we need passdb entries for every user we're exporting ? I mean it's being used by code. The problem is mainly on the fileserver: For the DC side of things, every user is in the SAM, or they can't really do much. But on the fileserver side, we have the problem that a user may select to view the Owner or the ACL entries of a file. I think we should simply document the fact the admins should really map each user or groups that own files on the shares, and if they do not do it they may get in troubles. When they do not do it, I think we should simply return a simple Unknown SID allocated for that purpose. This will eliminate the problem and make us not need algorithmic mapping at all, that is however wrong solution, as today also the uid/gid space is 32 bit as rid space so that we can go out of mapping space anyway and need to handle that situation too. Algorithmic mapping should go away completely imho. Simo. -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: [PATCH] sam backend parameter
Simo Sorce wrote: On Thu, 2002-10-03 at 08:06, Andrew Bartlett wrote: [EMAIL PROTECTED] wrote: Let just remove the multi-domain stuff for now and try and get 3.0 in a shippable state. The 'new SAM' stuff is not being proposed for 3.0! Certainly not yet, we have a *lot* of work to do, before it gets there! Also, *please* don't confuse that with the multi-backend stuff. That has a very different purpose, and was not included in the new SAM design for exactly the reasons people don't want it in passdb. The use of multiple backends in passdb has acknowledged issues, and I'm not particularly fussed if you feel it should not ship with this functionality enabled. However, please do note that this *is* being used at present, and cannot be 'just removed'. (We map our non-passdb users into the system via this method). Volker has some solutions to this issue however, which look very neat. I'll need to check if they actually catch it all the cases. So let me understand: you say sam will not be in 3.0 I did not say that. I said that I have not yet proposed the SAM for 3.0. I will not propose it for 3.0 until it's ready. you see currently passdb has been made so that nobody like it and is not good I think the structure in the passdb code is OK. The mulibackend issues are minor, and are quite well suited to inclusion in a module. I'll let others comment on what is so broken about it (particularly compared to 2.2) and how to fix it within the current constraints. but you also say we should not end up using a correct solution because you want to maintain the status quo? 'a correct solution'? I am working hard on the 'new SAM' stuff because I believe it to be a 'correct solution'. I am also actively reviewing proposed changes to passdb. We have to fix passdb or sam, just let decide on which one we should work on or go for a third way. I've seen Volker's patches, and I think that passdb can be made to work for the needs of 3.0, but it is messy. I believe the code as it *currently stands* can support 'net rpc vampire', but will consult volker more closely on this matter. I'm very impressed with voker's work in doing many of the things that were not thought possible with passdb. Of course I would much prefer we move directly to the 'new SAM' work, but I'll see the guidance of the release manager on that point, when I think the code is ready. 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: [PATCH] sam backend parameter
On Thu, 2002-10-03 at 12:34, Andrew Bartlett wrote: Simo Sorce wrote: It is all a question on how and where you use them. ^^ Except that global variables are particularly nasty in C - we don't have an autoprototyper on them, and we cannot ensure that they are correctly declared in all modules. Also, we cannot validate the input into any such variables, or assume auto-initialisation. The methods employed in the pdb and sam provide this. Honestly, it is a matter of taste. I like the way that pdb (and now the SAM code) has been constructed, and the distinct lack of 'special cases'. If pdbedit becomes a special case, then it is more likely to break. If the rest of Samba has to use that code path, then accidents are less likely to happen. pdbedit is not a special case, it only uses the backend interface and not the sam interface, they will be both quite consistent! No better the backend interface should be even more solid and stable then sam interface as it have to deal with potentially external modules, so i really do not see pdb/sam/gums/**edit to break so easily. | smbd| --- | --- |sam interface| --- | |--| pdbedit | --- | backend | --- Effort should be spent to educate other programmers to use the thing the right way by writing documentation, not by setting artificial barriers. Here we disagree. I take a different approach, were I prefer to make it harder to make mistakes. Harder to make mistake is good only when it does not imply harder to code. I abide to the Keep it Simple Stuipd! religion :-) The use of 'set' routines has also allowed us to (with minimal changes to the interface) track 'default' values for many parameters - avoiding the storage of extra (fixed) values in LDAP. I intend to expand this to every attribute for the new SAM. The set routines may stay at the sam interface level, nobody prohibits you to use them and they are certainly appealing in some situation, even if I do not like them much and would prefer do be able to change a structure directly if I need to do it (again I have to remember we are using C not Java, and an object oriented way to do things is not always a good thing imho). Also I think it is bad you do not put extra values in LDAP, what happen if you discover you need to support that to provide some functionality? A re you going to change the LDAP schema between minor releases? Furthermore, we use the get/set routines to allow the users of the passdb interface to get feedback on the ability to get/set *individual* elements on the SAM handle, rather than the lot. ability to set/get individual values ? What do you exactly mean ? I advocate strong interfaces, because I feel it assists in modular programming. By using the get/set routines, I can ensure that data is correctly 'const', for example. Finally, it allows us to strdup() all assigned strings, and ensure they are not accidentally assigned stack pointers, while avoiding memory leaks. On a project as large as Samba, I prefer all the help I can get in ensuring code quality. You will get more quality documenting it then making barriers into it imho. I'm not saying we do not need clean interfaces, but that we should just not push too much. It must be in the Interface, putting it on the backend is the wrong move for many reasons: - code duplication, you have to implement the access checking into evry backend. - code review, authorization is a critical part of the security in samba, if you have to double check every module to be sure it does things the right way, you simply castrate the potentiality of a loadble module interface, as you put too much responsibility on independent module coders. - consistency every change you need to make to the access checking code, bust be made to any module and will make out of sync any modules not under your control, increasing the module versioning nightmare. - races may be easily solved supporting locks on the backend. We cannot assume locks in the backend. The interface is not designed in isolation - we have to work with the fact that LDAP *will* be a primary backend, and does not support this kind of locking. I prefer to create a solution that does not impose additional constraints on this. We can of course. There are many way to simulate locks even for ldap, as it is clear that people should not be able to change user values if not going through samba. Reading is not a problem, we only need lock on write. Your points are very valid, and I have proposed a solution in the my reply to Jerry's mail. That is, the backend can do it's own ACL checks if it likes, but it passes the security descriptor to the
Re: [PATCH] sam backend parameter
On Thu, Oct 03, 2002 at 09:25:39PM +1000, Andrew Bartlett wrote: I've seen Volker's patches, and I think that passdb can be made to work for the needs of 3.0, but it is messy. I believe the code as it *currently stands* can support 'net rpc vampire', but will consult volker more closely on this matter. I'm very impressed with voker's work in doing many of the things that were not thought possible with passdb. net rpc vampire is one of the most important elements of 3.0. Anything that makes this function easier is a major priority. If fixing the passdb backend gets us there then let's do that and experiment with the SAM stuff later. Jeremy.
Re: [PATCH] sam backend parameter
Gerald Carter wrote: On Tue, 1 Oct 2002, Eddie Lania wrote: Like I've said, I'm not a developer, but maybe the multiple domain support parameter could be extended with the backend method? Like this: multiple domain support = DOMA:backendA, DOMB:backendB, etc Can someone please explain the purpose of supporting accounts from different domains in a single SAM ? Why would we ever want to do this? No, the idea is that one SAM backend would know about only one domain, but that we could have multiple domains, each with their own backend. For smbd it doesn't make much sense, except that I was looking at handling 'builtin' stuff by abstraction into a separate 'domain' this way. (I favor putting special cases into modules, rather than in interfaces). The other cases for 'multiple domain' support involve the way these users are reflected back into unix by winbindd, which might be running on a system that has multiple, independent smbd instances on separate IPs. In any case, the syntax will need to get much clearer if this is to stay around for long. (idra seems determined to kill it). 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: [PATCH] sam backend parameter
On Wed, Oct 02, 2002 at 09:19:47AM -0500, Gerald Carter wrote about 'Re: [PATCH] sam backend parameter': On Tue, 1 Oct 2002, Eddie Lania wrote: Like I've said, I'm not a developer, but maybe the multiple domain support parameter could be extended with the backend method? Like this: multiple domain support = DOMA:backendA, DOMB:backendB, etc Can someone please explain the purpose of supporting accounts from different domains in a single SAM ? Why would we ever want to do this? Builtin or multi-domain DC afaik - Kai and Andrew know all the how's and why's. Jelmer -- Jelmer Vernooij [EMAIL PROTECTED] Pending (unfinished) patches http://samba.org/~jelmer/diffs.php
Re: [PATCH] sam backend parameter
On Thu, Oct 03, 2002 at 12:30:30AM +1000, Andrew Bartlett wrote: Gerald Carter wrote: On Tue, 1 Oct 2002, Eddie Lania wrote: Like I've said, I'm not a developer, but maybe the multiple domain support parameter could be extended with the backend method? Like this: multiple domain support = DOMA:backendA, DOMB:backendB, etc Can someone please explain the purpose of supporting accounts from different domains in a single SAM ? Why would we ever want to do this? No, the idea is that one SAM backend would know about only one domain, but that we could have multiple domains, each with their own backend. For smbd it doesn't make much sense, except that I was looking at handling 'builtin' stuff by abstraction into a separate 'domain' this way. (I favor putting special cases into modules, rather than in interfaces). The other cases for 'multiple domain' support involve the way these users are reflected back into unix by winbindd, which might be running on a system that has multiple, independent smbd instances on separate IPs. Use vmware or virtual hosts for this. It's not something that Samba needs to be architectured around. In any case, the syntax will need to get much clearer if this is to stay around for long. (idra seems determined to kill it). Me too. This is too ugly to live. I also don't agree that BUILTIN should be handled as a separate domain. The multiple domain stuff really has to go, as Gerry says, why would anyone want to do that ? Jeremy.
Re: [PATCH] sam backend parameter
- what is all the context thing needed for? Sometimes we need multiple contexts. For example, when doing sam2sam. Please notice that passdb has this as well... Jelmer -- Jelmer Vernooij [EMAIL PROTECTED] - http://nl.linux.org/~jelmer/ Development And Underdevelopment: http://library.thinkquest.org/C0110231/ Listening to 23:55:29 up 11:49, 10 users, load average: 0.27, 0.39, 0.39
Re: [PATCH] sam backend parameter
Gerald Carter wrote: On Wed, 2 Oct 2002 [EMAIL PROTECTED] wrote: The other cases for 'multiple domain' support involve the way these users are reflected back into unix by winbindd, which might be running on a system that has multiple, independent smbd instances on separate IPs. OK. I just caught this. One winbnidd install serving multiple smbd installations on the same host? This seems like complicating the a corner case requirement. My concern is about the ongoing maintainence and administration of the code. Code that is only understood by one person is unmaintainable code. Nothing against you mind you. If i was the only one who understand how our printer change notify code worked for example, I would argue the same point. It could also be that the only one person understands it phenomena it partly our fault as well for not digging in earlier. Water under the bridge at this point. Well work on it better in the future :-) The only reason we have this code at all is becouse it *is* simple. Current problems with how to specify it in smb.conf aside, the relevent code is not long, nor complex. We would need almost as many lines of code if we were to kill it, becouse we need to verify these things anyway. (That a sensible 'domain' or 'domain sid' has been passed). 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: [PATCH] sam backend parameter
Simo Sorce wrote: Plus I have some questions about the current sam interface: - what is all the context thing needed for? I don't like global variables, and this allows us to construct seperate contexts for operations like sam2sam, and testing, without fiddiling with global variables. - what is the handle thing needed for ? Same as the SAM_ACCOUNT in pdb. - what is access desired meant to do ? Authorization is a different thing then storage, a backend is a storage! The SAM interface layer is the 'choke point'. If we do not wan't nasty races, then we must reterive things like the security descriptor with the data it applies to. This implies that the ACL checking code must resise either in the SAM backend, or the SAM interface. If we export it above this layer, we *will* get places where we don't check it properly. - why do we insist to have a thing called unix accounts? It just does not make sense to me. We need real users/groups mapping instead (opposed to created on the fly by winbind based accounts). I'm not sure what you mean here - the current code doesn't even know about unix accounts. 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: [PATCH] sam backend parameter
On Thu, Oct 03, 2002 at 12:16:53AM +0200, Simo Sorce wrote about 'Re: [PATCH] sam backend parameter': yes a thing I'm not sure has ever been a good idea. to be able to have sam2sam that is really read a backend + store all info into another backend we may take several ways. We never need the 2 backend to be loaded at the same time to do the operation, we may easily read all the accounts chnage the backend and store them into the new one, or simply make custom code to load 2 different backends, and use theyr calls. It's easy to have 2 structures calle backend1 and backend2 that holds the functon pointers for 2 backends. Al the context things always seemed to me overcomplicated even for multiple backend code. the context stuff has been in passdb since the beginning and is not at all used for multiple backends - multiple backends are achieved by having multiple 'methods' structs in one context. Next to that, a 'multidb' backend will have to use multiple contexts. We don't want to spoil global name space with the variables sam_context contains. If we are removing multiple domain support, we could remove sam_methods perhaps and move all the functions in sam_methods to sam_context, but sam_context definitely has to stay... Jelmer On Wed, 2002-10-02 at 23:56, Jelmer Vernooij wrote: - what is all the context thing needed for? Sometimes we need multiple contexts. For example, when doing sam2sam. Please notice that passdb has this as well... -- Jelmer Vernooij [EMAIL PROTECTED] - http://nl.linux.org/~jelmer/ Development And Underdevelopment: http://library.thinkquest.org/C0110231/ Listening to 07:18:45 up 12 min, 4 users, load average: 0.09, 0.05, 0.01
Re: [PATCH] sam backend parameter
Simo Sorce wrote: Multi domain DC is never going to happen in samba, it just doesn't make sense, as the protocols used (eg. SMB) will not be able to support such thing, so please let's stop to talk about multi-DC samba. I'm not so sure on this one. Some parts of the protocol might need to be told 'if not specified, use this', but I'm not sure the statement holds across everything. For example, I don't see any reason why we can't 'pretend' that any secondary domain is a 'trusted domain'. This would allow (for example) a resource DC, which has each machine in it, but no users, and an organizational DC to coexist nicely. (This is quite a common setup, btw). The advantage is that this one installation could have the 'organizational' users in replicated LDAP, so it would not need to make external connections for authentication. For the rare cases where clients contact the trusted domain directly, we could have either a separate Samba on another IP, or they could contact the remote DC directly. I see this as a powerful way to push Samba into places that it currently can't go, and I would like a chance to explore it. 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
[PATCH] sam backend parameter
Hi Jelmer,
here's a patch witch changes the syntax of the sam backend parameter:
now it's plugin[|DOMAIN][:options] ... I think it nicer:-)
If you didn't accept that patch please move the 'strchr' to 'strrchr', (but
there're also a few other bugs, in the parsing sam_backend_string in
make_backend_entry()), because as it is now it didn't work with:
plugin[:options][|DOMAIN] :-(
plugin:/usr/lib/samba/sam_passdb.so:test|test2:test3|test4|MX.BASE
breaks it...
metze
-
Stefan metze Metzmacher [EMAIL PROTECTED]
diff -Npur --exclude=CVS --exclude=*.bak --exclude=*.o --exclude=*.po --exclude=.#*
HEAD/source/sam/interface.c HEAD-fix/source/sam/interface.c
--- HEAD/source/sam/interface.c Mon Sep 30 07:29:04 2002
+++ HEAD-fix/source/sam/interface.c Tue Oct 1 09:35:27 2002
@@ -136,23 +136,22 @@ static NTSTATUS make_backend_entry(SAM_B
SAM_ASSERT(sam_backend_string backend_entry);
- backend_entry-module_name = sam_backend_string;
-
- DEBUG(5,(makeing backend_entry for %s\n, backend_entry-module_name));
-
+ DEBUG(5,(makeing backend_entry for %s\n, sam_backend_string));
+
+ if ((tmp = strchr(tmp_string, ':')) != NULL) {
+ *tmp = 0;
+ backend_entry-module_params = smb_xstrdup(tmp + 1);
+ DEBUG(20,(options for the backend:
+%s\n,backend_entry-module_params));
+ }
+
if ((tmp = strchr(tmp_string, '|')) != NULL) {
- DEBUGADD(20,(a domain name has been specified\n));
*tmp = 0;
backend_entry-domain_name = smb_xstrdup(tmp + 1);
- tmp_string = tmp + 1;
+ DEBUGADD(20,(the domain name is: %s\n,backend_entry-domain_name));
}
- if ((tmp = strchr(tmp_string, ':')) != NULL) {
- DEBUG(20,(options for the backend have been specified\n));
- *tmp = 0;
- backend_entry-module_params = smb_xstrdup(tmp + 1);
- tmp_string = tmp + 1;
- }
+ backend_entry-module_name = smb_xstrdup(tmp_string);
+ DEBUGADD(20,(module name is: %s\n, backend_entry-module_name));
if (backend_entry-domain_name == NULL) {
DEBUG(10,(make_backend_entry: no domain was specified for sam module
%s. Using default domain %s\n,
diff -Npur --exclude=CVS --exclude=*.bak --exclude=*.o --exclude=*.po --exclude=.#*
HEAD/source/torture/cmd_sam.c HEAD-fix/source/torture/cmd_sam.c
--- HEAD/source/torture/cmd_sam.c Mon Sep 30 07:29:04 2002
+++ HEAD-fix/source/torture/cmd_sam.c Tue Oct 1 09:26:32 2002
@@ -61,7 +61,7 @@ static NTSTATUS cmd_load_module(struct s
}
if (argc == 3)
- asprintf(plugin_arg[0], plugin:%s|%s, argv[1], argv[2]);
+ asprintf(plugin_arg[0], plugin|%s:%s, argv[2], argv[1]);
else
asprintf(plugin_arg[0], plugin:%s, argv[1]);
[PATCH] sam backend parameter
Well, I'm starting to think our syntax is just getting too complex. All the 'solutions' for putting 'domain' in there just look ugly! Some poor admin has to construct this line, and even if they don't use multidomain stuff (and that's almost everybody), then have to read the doco that attempts to explain it. I think we should remove the DOMAIN bit compleatly, and allow backends to store both their own SID and thier domain name. If they don't 'know' it, then they can either chose the default, or use a 'parametric option' to specify it. What about using the WORKGROUP parameter as the default domain vallue? And an extra parameter like multiple domain support = False|DOMAIN1,DOMAIN2,etc? It's just an idea, I am not a developper myself tough. Eddie.
Re: [PATCH] sam backend parameter
Eddie Lania wrote: Well, I'm starting to think our syntax is just getting too complex. All the 'solutions' for putting 'domain' in there just look ugly! Some poor admin has to construct this line, and even if they don't use multidomain stuff (and that's almost everybody), then have to read the doco that attempts to explain it. I think we should remove the DOMAIN bit compleatly, and allow backends to store both their own SID and thier domain name. If they don't 'know' it, then they can either chose the default, or use a 'parametric option' to specify it. What about using the WORKGROUP parameter as the default domain vallue? And an extra parameter like multiple domain support = False|DOMAIN1,DOMAIN2,etc? It's just an idea, I am not a developper myself tough. Eddie. I don't think the WORKGROUP parameter is the right one. winbindd has the same problem when you specify use default domain = yes. It chooses the WORKGROUP but that is not always what is wanted. Many people have a setup where all user accounts are in an authentication domain and all machines go into different resource domains with trust relationships set up between the domains. In this case it would be nice for winbindd to use the default authentication domain not the resource domain listed in WORKGROUP for the user/group mapping. Unfortunately I think we need another parameter other than WORKGROUP to specify the default domain to give us the flexibility for cases like this.
Re: [PATCH] sam backend parameter
On Tue, Oct 01, 2002 at 12:59:47PM +0200, Eddie Lania wrote: Well, I'm starting to think our syntax is just getting too complex. All the 'solutions' for putting 'domain' in there just look ugly! Some poor admin has to construct this line, and even if they don't use multidomain stuff (and that's almost everybody), then have to read the doco that attempts to explain it. I think we should remove the DOMAIN bit compleatly, and allow backends to store both their own SID and thier domain name. If they don't 'know' it, then they can either chose the default, or use a 'parametric option' to specify it. What about using the WORKGROUP parameter as the default domain vallue? And an extra parameter like multiple domain support = False|DOMAIN1,DOMAIN2,etc? It's just an idea, I am not a developper myself tough. What domainname/domainsid would belong to what sam backend then...? Jelmer
Re: [PATCH] sam backend parameter
Well, I'm starting to think our syntax is just getting too complex. All the 'solutions' for putting 'domain' in there just look ugly! Some poor admin has to construct this line, and even if they don't use multidomain stuff (and that's almost everybody), then have to read the doco that attempts to explain it. I think we should remove the DOMAIN bit compleatly, and allow backends to store both their own SID and thier domain name. If they don't 'know' it, then they can either chose the default, or use a 'parametric option' to specify it. What about using the WORKGROUP parameter as the default domain vallue? And an extra parameter like multiple domain support = False|DOMAIN1,DOMAIN2,etc? It's just an idea, I am not a developper myself tough. What domainname/domainsid would belong to what sam backend then...? Like I've said, I'm not a developer, but maybe the multiple domain support parameter could be extended with the backend method? Like this: multiple domain support = DOMA:backendA, DOMB:backendB, etc But I guess this will be to long too. That is actually the way 'sam backends' is at the moment... Jelmer
Re: [PATCH] sam backend parameter
On Tue, Oct 01, 2002 at 09:48:34AM +0200, Stefan (metze) Metzmacher wrote about '[PATCH] sam backend parameter': Hi Jelmer, here's a patch witch changes the syntax of the sam backend parameter: now it's plugin[|DOMAIN][:options] ... I think it nicer:-) If you didn't accept that patch please move the 'strchr' to 'strrchr', (but there're also a few other bugs, in the parsing sam_backend_string in make_backend_entry()), because as it is now it didn't work with: plugin[:options][|DOMAIN] :-( plugin:/usr/lib/samba/sam_passdb.so:test|test2:test3|test4|MX.BASE breaks it... This would be fixed by changing strchr to strrchr... Your patch would break backwards compatibility, and that's where this format was aimed at initially.. Secondly, having the backend and the backend parameters seperated is not very logicial, especially for plugin. Jelmer
