On Mon, Apr 23, 2012 at 07:27:55AM -0400, Stephen Gallagher wrote: > On Mon, 2012-04-23 at 10:56 +0200, Sumit Bose wrote: > > On Fri, Apr 20, 2012 at 03:01:17PM -0400, Stephen Gallagher wrote: > > > On Fri, 2012-04-13 at 12:34 +0200, Jan Zelený wrote: > > > > > > > > Hi Stephen, > > > > I went through all patches and I have couple things which I'd like to > > > > ask you > > > > about. First of all I'm not that familiar with ID mapping in winbind so > > > > my > > > > questions might be trivial. If yes, sorry for that. > > > > > > > > First thing: I'd like to know a bit more about those slices, range and > > > > this > > > > sort of stuff. I mean like the background and ideas behind it. It might > > > > be a > > > > good thing to include some information or pointers to other > > > > documentation into > > > > our man pages. > > > > > > > > > > Yes, as I mentioned in the patches, I need to write manpages for these > > > things. So the main topics are lower and upper limits, ranges and > > > slices. > > > > > > The lower and upper limit provides the minimum and maximum pool of IDs > > > that we can draw from. Rangesize is how many IDs will constitute a > > > single slice. So each slice contains rangesize uids and there are > > > rangesize / (upper-lower) available slices. Each slice will hold the IDs > > > for one domain. > > > > > > So in the default case: > > > ldap_idmap_range_min = 100,001 > > > ldap_idmap_range_max = 2,000,100,000 > > > ldap_idmap_range_size = 100,000 > > > > > > > > > So what this means is that we will have 2000 available slices each > > > capable of managing up to 100,000 IDs. > > > > > > > About the general approach I have only one comment. I don't really like > > > > two > > > > different approaches to storing the domain sid - as string and as a > > > > struct. > > > > Would it make any sense to unify all ID mapping code to be working with > > > > one > > > > data format? > > > > > > > > > > Well, the ID-mapping library that Sumit wrote takes the string format, > > > so I was working with that. However, it's difficult at best to get there > > > from the representation stored in LDAP without converting it through the > > > struct. Unless Sumit wants to change the ID-mapping library to take > > > struct dom_sid, it's probably fine to just leave this as-is. > > > > > > I could have made the conversion function a single one, but it seemed > > > potentially handy to have them be separate. > > > > I tried to keep the idmap library simple and tried to avoid adding > > functionality which I did no need. But I think is would make sense to > > enhance the interface to allow the usage of binary SIDs and struct > > dom_sid as well. > > > > Stephen, what do you think of adding the definition of struct dom_sid > > and the conversion calls to the idmap library? I you prefer I can do it > > and then you can rebase your patch on top of the new version of the > > idmap library? > > Sure, I'm amenable to that. If you want to do it, that would be > preferable to me. I've still got a lot of work to do for the 1.9 beta > release.
sure, no problem, here is a sketch about the possilbe additions to libidmap. Would this work for you? diff --git a/src/lib/idmap/sss_idmap.h b/src/lib/idmap/sss_idmap.h index dbb2700..3855d9c 100644 --- a/src/lib/idmap/sss_idmap.h +++ b/src/lib/idmap/sss_idmap.h @@ -74,6 +74,15 @@ enum idmap_error_code { typedef void *(idmap_alloc_func)(size_t size, void *pvt); typedef void (idmap_free_func)(void *ptr, void *pvt); +#define SID_ID_AUTHS 6 +#define SID_SUB_AUTHS 15 +struct dom_sid { + uint8_t sid_rev_num; + int8_t num_auths;/* [range(0,15)] */ + uint8_t id_auth[SID_ID_AUTHS]; + uint32_t sub_auths[SID_SUB_AUTHS]; +}; + /** * Structure for id ranges * FIXME: this struct might change when it is clear how ranges are handled on @@ -145,6 +154,15 @@ enum idmap_error_code sss_idmap_sid_to_unix(struct sss_idmap_ctx *ctx, const char *sid, uint32_t *id); +enum idmap_error_code sss_idmap_dom_sid_to_unix(struct sss_idmap_ctx *ctx, + struct dom_sid *dom_sid, + uint32_t *id); + +enum idmap_error_code sss_idmap_bin_sid_to_unix(struct sss_idmap_ctx *ctx, + uint8_t *bin_sid, + size_t length, + uint8_t *bin_sid, + size_t length, + uint32_t *id); + /** * @brief Translate unix UID or GID to a SID * @@ -162,6 +180,15 @@ enum idmap_error_code sss_idmap_unix_to_sid(struct sss_idmap_ctx *ctx, uint32_t id, char **sid); +enum idmap_error_code sss_idmap_unix_to_dom_sid(struct sss_idmap_ctx *ctx, + uint32_t id, + struct dom_sid **dom_sid); + +enum idmap_error_code sss_idmap_unix_to_bin_sid(struct sss_idmap_ctx *ctx, + uint32_t id, + uint8_t **bin_sid, + size_t *length); + /** * @brief Free all the allocated memory of the idmap context * @@ -193,6 +220,27 @@ const char *idmap_error_string(enum idmap_error_code err); */ bool is_domain_sid(const char *str); +enum idmap_error_code sss_idmap_bin_sid_to_dom_sid(const uint8_t *bin_sid, + size_t length, + struct dom_sid **dom_sid); + +enum idmap_error_code sss_idmap_bin_sid_to_sid(const uint8_t *bin_sid, + size_t length, + char **sid); + +enum idmap_error_code sss_idmap_dom_sid_to_bin_sid(struct dom_sid *dom_sid, + const uint8_t **bin_sid, + size_t *length); + +enum idmap_error_code sss_idmap_sid_to_bin_sid(char *sid, + const uint8_t **bin_sid, + size_t *length); + +enum idmap_error_code sss_idmap_dom_sid_to_sid(struct dom_sid *dom_sid, + char **sid); + +enum idmap_error_code sss_idmap_sid_to_dom_sid(char *sid, + struct dom_sid **dom_sid); /** * @} */ bye, Sumit _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel