On Sat, Feb 3, 2018 at 8:28 AM, Richard Sharpe <realrichardsha...@gmail.com> wrote: > On Fri, Feb 2, 2018 at 1:07 AM, Sumit Bose <sb...@redhat.com> wrote: >> On Thu, Feb 01, 2018 at 01:03:24PM -0800, Richard Sharpe wrote: >>> Hi folks, >>> >>> We have a customer who seems to do what RHEL does with respects users >>> and groups. >>> >>> That is: >>> >>> 1. User A has a SID of S-1-5-21-x-y-z-1234 >>> 2. They also have a primary group SID of S-1-5-21-x-y-x-1235 (usually >>> adjacent). >>> 3. They are also using RFC2703bis and they have the UID property set >>> to 21234 and the GID property set to 21234. >>> >>> Now, when the Samba idmap_sss.c calls sss_nss_getsidbyid looking for >>> the SID associated with the GID it often gets back the SID associated >>> with the UID, probably because we just asked for the SID associated >>> with the UID. >>> >>> Is there a different function I can call to get both/all? I looked at >>> the code for sss_nss_getsidbyid and it just calls sss_nss_getyyybyxxx >>> and that function seems to only hand back the first SID returned. >> >> I'm sorry, I have to admit that this kind of setup didn't came to my >> mind when writing those calls. But yes, users and group are coming from >> different name spaces on the POSIX side and should be handled >> separately. >> >> Currently you can only do workarounds. E.g. if the group name differs >> from the user name you call getpwuid() and getgrgid() first and then >> sss_nss_getsidbyname(). But this would only work if the use names based >> on the samAccountName attribute from AD because iirc AD enforces >> uniqueness here. If they use a different attribute for the group names >> this might not work. >> >> As an alternative, but even more complicated you can make the SID >> available via D-Bus/InfoPipe and then lookup user and group by ID. >> >> So it looks like sss_nss_getsidbyuid() and sss_nss_getsidbygid() should >> be added to the interface. Would you mind to open a ticket about this on >> https://pagure.io/SSSD/sssd/new_issue or do you prefer me doing this? > > Hmmm, it looks like all I might have to do is to add a couple of > simple routines to src/responder/nss/nss_cmd.c like this > > static errno_t nss_cmd_getsidbyid(struct cli_ctx *cli_ctx) > { > const char *attrs[] = { SYSDB_SID_STR, NULL }; > > return nss_getby_id(cli_ctx, false, CACHE_REQ_OBJECT_BY_ID, attrs, > SSS_MC_NONE, nss_protocol_fill_sid); > } > > except replacing SSS_MC_NONE with SSS_MC_PASSWD or SSS_MC_GROUP and > add SSS_NSS_GETSIDBYUID and SSS_NSS_GETSIDBYGID and plumb it all the > way through. > > Could be wrong because I am still reading the code.
That attached patch seems like it could go close to doing what I want. It seems there are no cmocka tests for sss_nss_getsidbyid as well, so there was nothing for me to copy there. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)
sssd-change-for-getsidby[ug]id.patch
Description: Binary data
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
