[SSSD] Re: Is there an alternative other than sss_nss_getsidbyid that can deal with UID == GID?

[Richard Sharpe]

On Sat, Feb 3, 2018 at 8:28 AM, Richard Sharpe
 wrote:
> On Fri, Feb 2, 2018 at 1:07 AM, Sumit Bose  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

[SSSD] Re: Is there an alternative other than sss_nss_getsidbyid that can deal with UID == GID?

[Richard Sharpe]

On Fri, Feb 2, 2018 at 1:07 AM, Sumit Bose  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.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: Is there an alternative other than sss_nss_getsidbyid that can deal with UID == GID?

[Richard Sharpe]

On Fri, Feb 2, 2018 at 1:07 AM, Sumit Bose  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?

I can file a ticket.

>>
>> Also, as an aside, it seems like a bad decision to place fixed CERTs
>> in the repos because if you need to rebuild the package after the CERT
>> expires you are SOL.
>
> Yes, makeshift solutions have a long life. I already have a ticket to
> generate fresh certificates for each test run
> https://pagure.io/SSSD/sssd/issue/3436. But only two tests should be hit
> by the issue. So, in the worst case they can be disabled:
>
> +diff --git a/Makefile.am b/Makefile.am
> +index
> 5635a8c8fd681c4a17d003487e9ea440ab431407..c230d5e69320206778637ee3d30bedf9fe2e000a
> 100644
> +--- a/Makefile.am
>  b/Makefile.am
> +@@ -273,11 +273,9 @@ if HAVE_CMOCKA
> + responder_cache_req-tests \
> + test_sbus_opath \
> + test_fo_srv \
> +-pam-srv-tests \
> + test_ipa_subdom_util \
> + test_tools_colondb \
> + test_krb5_wait_queue \
> +-test_cert_utils \
> + test_ldap_id_cleanup \
> + test_data_provider_be \
> + test_dp_request_table \
>
>
> HTH
>
> bye,
> Sumit
>
>>
>> --
>> Regards,
>> Richard Sharpe
>> (何以解憂？唯有杜康。--曹操)
>> ___
>> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org



-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: Is there an alternative other than sss_nss_getsidbyid that can deal with UID == GID?

[Richard Sharpe]

On Fri, Feb 2, 2018 at 3:56 AM, Sumit Bose  wrote:
> On Fri, Feb 02, 2018 at 11:46:03AM +0100, Jakub Hrozek wrote:
>> On Fri, Feb 02, 2018 at 10:07:08AM +0100, Sumit Bose wrote:
>> > 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?
>>
>> Maybe I misread your comment and you're actually proposing what I'm
>> going to say, but can you think of a reason to not expose the SID (if
>> availabel) on the D-Bus interface in the set of the default attributes?
>
> no, I just meant that from a C client perspective it might be more
> cumbersome and might add additional dependencies using the D-Bus
> interface to get this information compared to a library call.

Yeah, I wouldn't want to add more to the Samba idmap build ...

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: Is there an alternative other than sss_nss_getsidbyid that can deal with UID == GID?

[Sumit Bose]

On Fri, Feb 02, 2018 at 11:46:03AM +0100, Jakub Hrozek wrote:
> On Fri, Feb 02, 2018 at 10:07:08AM +0100, Sumit Bose wrote:
> > 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?
> 
> Maybe I misread your comment and you're actually proposing what I'm
> going to say, but can you think of a reason to not expose the SID (if
> availabel) on the D-Bus interface in the set of the default attributes?

no, I just meant that from a C client perspective it might be more
cumbersome and might add additional dependencies using the D-Bus
interface to get this information compared to a library call.

bye,
Sumit

> 
> Is there any information leak by this? I think not, because you can
> always open a python console for example and run the id-to-sid
> translation.
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: Is there an alternative other than sss_nss_getsidbyid that can deal with UID == GID?

[Jakub Hrozek]

On Fri, Feb 02, 2018 at 10:07:08AM +0100, Sumit Bose wrote:
> 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?

Maybe I misread your comment and you're actually proposing what I'm
going to say, but can you think of a reason to not expose the SID (if
availabel) on the D-Bus interface in the set of the default attributes?

Is there any information leak by this? I think not, because you can
always open a python console for example and run the id-to-sid
translation.
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: Is there an alternative other than sss_nss_getsidbyid that can deal with UID == GID?

[Sumit Bose]

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?

> 
> Also, as an aside, it seems like a bad decision to place fixed CERTs
> in the repos because if you need to rebuild the package after the CERT
> expires you are SOL.

Yes, makeshift solutions have a long life. I already have a ticket to
generate fresh certificates for each test run
https://pagure.io/SSSD/sssd/issue/3436. But only two tests should be hit
by the issue. So, in the worst case they can be disabled:

+diff --git a/Makefile.am b/Makefile.am
+index
5635a8c8fd681c4a17d003487e9ea440ab431407..c230d5e69320206778637ee3d30bedf9fe2e000a
100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -273,11 +273,9 @@ if HAVE_CMOCKA
+ responder_cache_req-tests \
+ test_sbus_opath \
+ test_fo_srv \
+-pam-srv-tests \
+ test_ipa_subdom_util \
+ test_tools_colondb \
+ test_krb5_wait_queue \
+-test_cert_utils \
+ test_ldap_id_cleanup \
+ test_data_provider_be \
+ test_dp_request_table \


HTH

bye,
Sumit

> 
> -- 
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org