i have a question for the people who sponsor the samba team. "when are you going to realise that your money is being wasted by not sponsoring me as a design architect on NT compatibility software suites for unix?" here - yet again, another demonstration of how much money you have been wasting. hopefully this time this "really new" proposal - i.e. yet ANOTHER idea and proposal introduced by me almost three years ago - will actually get done, and done properly. you lot: read http://cb1.com/~lkcl/cifs - the surs RFC. remember two and only three important things, and you will not go wrong. if you do not remember these three things, you WILL end up with complications, security flaws and unmanageable sites. 1) you MUST allow mapping of a SID to both a user AND a group id. 2) mappings of SIDs to user ids MUST be both "onto" and "one-to-one". 3) mappings of SIDs to group ids MUST be both "onto" and "one-to-one". yet another demonstration of how arrogance, pride and cruelty can set a project back years by the simple expedient of not being willing to listen to people who know what they're talking about. i'm specifically referring to you - andrew - and you - jeremy.> Hi, > > here's a proposal for the idmap api; > > we'll have a cache that will be asked first, if this fails we ask the > central idmap and add the result to our cache. > > the idmap_central_* functions should be plugable/selectable (different > backends should be allowed here) > > and the backend should decide how to handle unmapped id's. > > comments please > > /* idmap api */ > NT_STATUS idmap_sid_to_id(DOM_SID *sid, int *id, BOOL *group); > { > if (NT_STATUS_IS_OK(idmap_cache_sid_to_id(sid,id,group))) > { > return NT_STATUS_OK; > } > > if (!NT_STATUS_IS_OK(idmap_central_sid_to_id(sid,id,group))) > { > return NT_STATUS_UNSUCCESFUL; > } > > idmap_cache_update(sid,id,group); > return NT_STATUS_OK; > } > > NT_STATUS idmap_uid_to_sid(uid_t uid, DOM_SID **sid); > { > if (NT_STATUS_IS_OK(idmap_cache_uid_to_sid(uid,sid))) > { > return NT_STATUS_OK; > } > > if (!NT_STATUS_IS_OK(idmap_central_uid_to_sid(uid,sid))) > { > return NT_STATUS_UNSUCCESFUL; > } > > idmap_cache_update(sid,uid,False); > return NT_STATUS_OK; > } > > NT_STATUS idmap_gid_to_sid(gid_t gid, DOM_SID **sid); > { > if (NT_STATUS_IS_OK(idmap_cache_gid_to_sid(gid,sid))) > { > return NT_STATUS_OK; > } > > if (!NT_STATUS_IS_OK(idmap_central_gid_to_sid(gid,sid))) > { > return NT_STATUS_UNSUCCESFUL; > } > > idmap_cache_update(sid,gid,True); > return NT_STATUS_OK; > } > > > metze > ----------------------------------------------------------------------------- > Stefan "metze" Metzmacher <metze@metzemix.de> > > > -- > Luke Howard | PADL Software Pty Ltd | www.padl.com-- ---------------------------------------------------------- this message is private, confidential, and is intented for the specified recipients only. if you received in error, altered, deleted, modified, destroyed or interfered with the contents of this message, in whole or in part, please inform the sender (that's me), immediately. if you, the recipient, reply to this message, and do not then receive a response, please consider your reply to have been lost or deliberately destroyed: i *always* acknowledge personal email received. please therefore take appropriate action and use appropriate protocols to ensure effective communication. thank you.
On Tue, Oct 22, 2002 at 06:02:35PM +0000, Luke Kenneth Casson Leighton wrote:> i have a question for the people who sponsor the samba team.Rantings and dribble deleted....> i'm specifically referring to you - andrew - and you - jeremy.> > here's a proposal for the idmap api;I take it by this message you didn't actually read or understand what this API is meant to do :-). Never mind, wouldn't be the first time (and sadly, probably not the last... :-). Luke, please just go away :-). Jeremy.
On Tue, 2002-10-22 at 14:02, Luke Kenneth Casson Leighton wrote:> i have a question for the people who sponsor the samba team. > > "when are you going to realise that your money is being > wasted by not sponsoring me as a design architect on > NT compatibility software suites for unix?"is this a joke?> yet another demonstration of how arrogance, pride and cruelty can > set a project back years by the simple expedient of not being > willing to listen to people who know what they're talking about.I was laughing out loud after i read this part. the arrogance and pride bit is the best. thanks for the levity. brad
On Tue, 2002-10-22 at 20:02, Luke Kenneth Casson Leighton wrote:> i have a question for the people who sponsor the samba team. > > "when are you going to realise that your money is being > wasted by not sponsoring me as a design architect on > NT compatibility software suites for unix?" >Probably you should understand that people may be interested in other features and not sponsoring this particular part of the code.> here - yet again, another demonstration of how much money you have > been wasting.Well let's look at the TNG printing code status ...> hopefully this time this "really new" proposal - i.e. yet > ANOTHER idea and proposal introduced by me almost three years > ago - will actually get done, and done properly.This is NOTHING new Luke, we know the SID-[g,u]id mapping problems since a lot of time, the fact that you formalized the problem does not change the problem. I just double checked your draft, and it is just nice useless wording that show the problem but does never even propose an implementation, you always write that implementation is not in the scope of the document. We have not implemented what you call SURS part because of lack of time being busy implementing other more important parts of samba, and part because we wanted to get it right (and we tought your implementation was not). The api proposed by metze is just an api proposal to finally start coding it having found a way to implement it the right way as we finally have found what seem the right way to do it, taking in account all limits and trying to find out the best compromise. This is the part the ask for more hard work. Plus we have not limited ourselves to solve the problem locally, but to solve the problem in a distributed environment. You may claim you have told there was a problem 3 years ago. Well that's true nobody say it different. Problem is that solving it 3 years ago was not possible to do properly, too many pieces of code were missing or were not stable and usable at a point that implementing it 3 years ago would have simply be a waste of time. with sincere esteem, Simo. -- Simo Sorce - simo.sorce@xsec.it Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.samba.org/archive/samba/attachments/20021022/3fedc1d6/attachment.bin
On Tue, Oct 22, 2002 at 11:56:46PM +0200, Simo Sorce wrote:> ask for more hard work. Plus we have not limited ourselves to solve the > problem locally, but to solve the problem in a distributed environment.yes: that was - and is - the whole point of sursswitch. having done the surs draft RFC, and outlining the issues in it, and specifically defining the problem and very specifically leaving the decisions up to the implementors, i then turned my focus onto possible implementations. the first actual successful SURS-compliant implementation, with definite limitations, is hard-coded into winbindd. The Plan was always to write sursswitch, with a complementary /etc/sursswitch.conf file, with features similar to nsswitch, but only offering one-to-one and onto SID <-> uid and SID <-> gid management. and making the winbindd code then be the first program to actually use sursswitch, followed by the second key point being smbd to use sursswitch, followed by the third one being smbrun, which spoolssd uses (or used to use). i hope that this both addresses your concerns and also hints at the scope of the work i intended (and still feel is necessary). l.