Modulize Group mapping

[Kai Krueger]

----- Original Message ----- 
From: "Stefan (metze) Metzmacher" <metze at metzemix.de> Sent: Thursday, June 13, 2002 12:07 PM


> >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 wouldn't include "SEC_DESC sd;" and "int members; DOM_SID **member_sids" in the struct,
as they are returned / set using the other functions.

does "eneum SID_NAME_USE sid_name_use;"  need to be included? wouldn't that be the same
as "BOOL global;"?

And the last thing I would change in GROUP_ENTRY is to leave out the (unix) gid. This will probably
need some more changes in samba but should be possible from what I've seen in the code. That
would allow a clean cut to the group api. Otherwise functions might query the unix groups directly
instead of using the group api  causing terrible inconsistency. If no reference to unix groups are
anywhere, except perhaps in the group backend depending on the implementation, this couldn't
happen.

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

Shortly after I had written the mail I noticed, that I made a mistake with the SDs.
The difference between the builitn domain SDs and normal domain SDs are mainly not in
alias level, but in domain level. As far as I know both builtin aliases and domain aliases can
be changed normally. It's just, that you can't delete or create new aliases in the builtin domain.
But that is controlled by the SDs at domain level and the access checks using SDs aren't implemented
yet (s. Access control to sam / _samr_query_sec_obj)
But I think it wouldn't be much of a hassle to include the two functions in the api anyway. You never
know what you might need them for in future.

> 
> Are you on IRC #samba-technical?
> 

Haven't been on it yet, but I'll try soon.

> 
> 
> metze
> -----------------------------------------------------------------------------
> Stefan "metze" Metzmacher <metze at metzemix.de>
> 

Kai