At 09:53 13.06.2002 +0200, Kai Krueger wrote:
>----- Original Message -----
>From: "Stefan (metze) Metzmacher" [EMAIL PROTECTED]  Sent: Wednesday, June 
>12, 2002 10:43 AM
>
> > Hi,
>
> > I've startet to make the group mapping code modulized in the way it is 
> done
> > in the auth and passdb subsystems.
>
>I think modularising the group mapping code is a good idea. However I'd 
>prefer to see
>and would want to help with, a little bit more "radical" approach to the 
>topic. I'd suggest, instead
>of creating a group _mapping_ api, create a group api.

nice approach.

>This would include storing member
>information in the groups. This would allow much more flexibility in samba 
>especially in the aliases.
>Currently only users can be added to aliases instead of users and groups, 
>as only useres can be
>added to unix groups. Therefore you can't include the Domain Admins group 
>in the Administrators
>alias and have to, if you want to include users in both, create two local 
>unix groups. Trying to map two
>nt groups to one unix group only works in one direction (nt->unix), so 
>that the nt_user_token for
>example would only include one of the groups and therefore access checking 
>would fail currently.
>
>With a group api including members and the appropriate backend that should 
>all hopefully work.
>Looking at the code, it will be some work to change all the references but 
>shouldn't be impossible.
>
> >
> > Here is my first version of the module API.
>
>My suggestion is something like the below. But it is more a thought till 
>now than a proper api
>
>BOOL add_group_entry (GROUP_INFO1 group, BOOL local_global, DOM_SID 
>domain, int32 *rid);
>BOOL update_group_entry(GROUP_INFO1 group, DOM_SID group_sid);
>BOOL del_group_entry(DOM_SID group_sid);
>BOOL enum_group_entries(DOM_SID domain, BOOL local_global, GROUP_INFO1 
>**groups);
>BOOL get_group_by_sid(DOM_SID group_sid, GROUP_INFO1 *group);
>BOOL get_group_by_ntname(char *name, BOOL local_global, GROUP_INFO1 *group);
>
>BOOL add_member to group(DOM_SID group_sid, DOM_SID member_sid);
>BOOL delete_member_from_group(DOM_SID group_sid, DOM_SID member_sid);
>BOOL enum_members_of_group(DOM_SID group_sid, DOM_SID **members);
>BOOL get_groups_of_user(DOM_SID user_sid, DOM_SID **group_sids);
>
>BOOL get_group_sd(DOM_SID group_sid, SEC_DESC *sd);
>BOOL set_group_sd(DOM_SID group_sid, SEC_DESC *sd);

>Instead of using the GROUP_INFO1 struct it is probably best to create a 
>new structure that
>doesn't contain the UNI_HDR and instead contains the SID of the group.

I would prefer to define a new struct called GROUP_ENTRY



typedef struct _GROUP_ENTRY {

         fstring nt_name;
         fstring comment;

         DOM_SID sid;
         gid_t gid;

         SEC_DES sd;

         BOOL global;

         int     members;
         DOM_SID **member_sids;

         enum SID_NAME_USE sid_name_use;

         PRIVILEGE_SET priv_set;

         /* specify the group mapping backend */
         struct group_map_methods *methods;
} GROUP_ENTRY



>I've included the get_group_sd, because that makes the handling of the 
>builtin domain and aliases
>easier. The differences between the normal domain and builtin can then be 
>done in higher level
>functions using the SDs.

I'm not familiar with SEC_DESC, I need to study this and find out why it 
should be easier to use them...

Are you on IRC #samba-technical?



metze
-----------------------------------------------------------------------------
Stefan "metze" Metzmacher <[EMAIL PROTECTED]>


Reply via email to