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]>
