> So, the real issue is SSSD's inability to support empty netgroup domain
> part, right?
Yes, that’s the real bug. It doesn’t appear that the other issues are serious,
as I can’t find any real appiication that uses the NIS entries as triples.
The sssd problem is moderately serious for me. I don’t want to put in an
arbitrary NIS domain name for a system that doesn’t use NIS, because even if it
works on the Netapp now, I’d be depending upon undocumented behavior or I’d
have to give it a dummy NIS domain. I’m reluctant to tell the Netapp that it’s
in a NIS domain that doesn’t exist. Who knows what it would do?
It could also be an issue for transition. Consider a situation like ours where
we’re combining a number of NIS domains into a single IPA domain. While we
could work around it, it would be cleanest for our netgroup entries not to have
a domain name, so it’s clear that they apply to all NIS domains. (In fact our
transition has gone far enough that this isn’t a real problem. We’re
decommissioning NIS pretty rapidly.)
> Can you point me to what you call RFC-defined behavior? Because I don't
> see RFC defining a behavior but rather a storage format (which is
> suboptimal but that's another story).
I guess it depends upon how you understand the RFC. Clearly it doesn’t matter
how you store data as long as you present it to the application the way the RFC
specifies. But in fact an LDAP query simply presents it as stored. So you have
to use the compat tree to get the defined results. Even there, there are
triples that would be valid under the RFC that you can’t generate. I agree that
there may be no actual applications that would do it, but that doesn’t seem
like something you want your directory services dictating.
In principle according to the documentation we could write an application that
checks access using both user and host from a triple. E.g.
(host1, user1, domain1)
would authorize applications running in domain1 to accept login from
user1@host1. You can’t reliably generate triples like that, because the
association between user and host isn’t stored. You can fake it, but the first
time a host is removed, or for mixes of internal and external hosts, you’ll get
unexpected behavior.
Since no known applications uses this, it’s probably not a serious bug, but I
wouldn’t have created a design that disallows it.
> On Nov 13, 2017, at 11:44 AM, Alexander Bokovoy <aboko...@redhat.com> wrote:
>
> On ma, 13 marras 2017, Charles Hedrick wrote:
>> Sure. We use netgroups for /etc/exports. The most natural format for triples
>> is
>>
>> (host,,)
>>
>> That’s the format Netapp documents. By default, ipa netgroup-add-member uses
>>
>> (host,-,domain)
>>
>> where domain seems to come from our Kerberos domain. Netapp
>> documentation requests leaving that field blank, though some
>> documentation suggests that if it’s filled in, they will ignore triples
>> where the domain doesn’t match the Netapp’s domain. We are no longer
>> using NIS, so as far as we know, the Netapp doesn’t have a NIS domain.
>> I think it’s safest to leave the field blank.
> IPA sets NIS domain by default to its primary domain (equal to IPA
> realm in lower case). This is just a default value.
>
>> I can do this in IPA. —nisdomain= will leave it blank. That results in
>>
>> (host,-,)
>>
>> That works with the Netapp. (I haven’t actually tried putting a domain in.)
>>
>> Unfortunately it won’t work with sssd, because sssd won’t show any
>> triples if the nisdomain isn’t set for that net group.
> So, the real issue is SSSD's inability to support empty netgroup domain
> part, right?
>
> This is the code in ipa_netgr_process_all():
> ...
> ret = sysdb_attrs_get_string(state->netgroups[i], SYSDB_NETGROUP_DOMAIN,
> &domain);
> if (ret != EOK) {
> goto done;
> }
> ...
>
> DEBUG(SSSDBG_TRACE_INTERNAL, "Putting together triples of "
> "netgroup %d\n", i);
> for (j = 0; j < uids_count; j++) {
> for (k = 0; k < hosts_count; k++) {
> triple = talloc_asprintf(state, "(%s,%s,%s)",
> hosts[k], uids[j],
> domain);
> if (triple == NULL) {
> ret = ENOMEM;
> goto done;
> }
>
> ret = sysdb_attrs_add_string(state->netgroups[i],
> SYSDB_NETGROUP_TRIPLE,
> triple);
> if (ret != EOK) {
> goto done;
> }
> }
> }
>
>
> So, if no domain is retrieved, no netgroup triple is generated by SSSD
> IPA provider. Note that this does not utilize compatibility netgroups
> subtree as generated by schema compatibility plugin (in
> cn=ng,cn=compat,$SUFFIX) but instead works directly with IPA netgroups.
>
> So our discussion about RFC2307bis is not really applicable here. If we
> consider the use case with a blank nisDomainName a valid one (and I
> think we can consider it), the code above needs to be fixed to allow
> such use. It is a fairly simple fix.
>
>> In general I don’t understand why IPA and sssd are using a nonstandard
>> representation of net groups. Why not just a collection of triples and
>> subgroups? As far as I can see RFC 2307bis has the same schema for net
>> groups as RFC 2307.
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-howard-rfc2307bis-02&data=02%7C01%7Chedrick%40rutgers.edu%7Cf9646a8052604f1a986208d52ab5d7d0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636461882863604783&sdata=f9gYACLOOqGX5J5tNizDcOIzLgIc8hIHkxjCm5Z4p%2BI%3D&reserved=0.
>> Is there a
>> later version of RFC 2307bis that I haven’t been able to find? Draft 2
>> is the latest at
>> tools.ietf.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org&data=02%7C01%7Chedrick%40rutgers.edu%7Cf9646a8052604f1a986208d52ab5d7d0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636461882863604783&sdata=U7g%2B9P0tpyoUKDR%2BXMT%2FZv%2ByMOE54h8m%2BFE8SLcLGxA%3D&reserved=0>.
>>
>> ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
>> DESC 'Abstraction of a netgroup. May refer to other
>> netgroups'
>> MUST cn
>> MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
>>
>> The representation used by IPA seems to be non-standard. I’d expect IPA
>> and sssd to allow me to add any triple I want that’s valid in a normal
>> net group file.
> You can read (old) explanation on why IPA has schema as it has:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freeipa.org%2Fpage%2FFreeIPAv2%3ADS_Design_Summary%23Netgroups&data=02%7C01%7Chedrick%40rutgers.edu%7Cf9646a8052604f1a986208d52ab5d7d0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636461882863604783&sdata=%2FrI6y%2FfFnmbCFN51ythOlxpgu72%2Fgku6fR4xT0Tow%2BQ%3D&reserved=0
>
>
>> One problem with the IPA representation is that there are no actual
>> triples. There’s a list of hosts, a list of users, and a domain. Not
>> all triples can be represented that way. Something like (host1, user1,)
>> (host2, user2,)
>> has to be represented by a user list of user1, user2 and a host list of
>> host1, host2. But the pairing isn’t always well defined. E.g. I added
>> to that group an external host3 and an internal user3. I ended up with
>>
>> (host3, user1,)
>> (host1, user2,)
>> (host2, user3,)
>>
>> I don’t know whether there are applications that use the pairing of
>> hosts and users, but the original design was intended to support that.
>> With IPA it’s dangerous, because I have to know just how IPA generates
>> the triples from the entires.
> Frankly speaking, original RFC2307bis design had very little explanation
> on the actual semantics. It just listed attributes and demonstrated
> their use in examples. Actual semantical meaning wasn't defined.
>
> In addition, NIS and NIS+ never had any RFC defined for them.
>
>> Is there a way to get the RFC-defined behavior from IPA and SSSD?
> Can you point me to what you call RFC-defined behavior? Because I don't
> see RFC defining a behavior but rather a storage format (which is
> suboptimal but that's another story).
>
>
>> We don’t actually have a user case for pairing. We just need a host
>> list. So for the moment the plan is to add hosts with nisdomain=, and
>> use nslcd in nsswitch.conf for net groups on the Linux systems that are
>> NFS servers.
> Right now IPA allows you to associate a hostgroup with a specific
> netgroup and schema compat plugin will automatically generate triples
> expressing this set. However, as I showed above, SSSD doesn't actually
> use this compatibility information at all. IPA provider sets netgroup
> search base to cn=ng,cn=alt,$SUFFIX, not cn=ng,cn=compat,$SUFFIX, so
> RFC2307bis-specific details are irrelevant in the case IPA provider is
> used.
>
>> I don’t have any specific use case for distinguishing between space and
>> -. But the spec says they mean something different. I don’t know why
>> you would adopt a representation that doesn’t allow for every valid
>> triple.
> I believe we do allow that and compat plugin actually generates them --
> except for empty nisDomainName attribute -- for which I provided a
> possible solution in my previous email.
>
> I'm yet to see your actual example. Let us set SSSD bug aside here.
> Please show a sequence of 'ipa netgroup-*' commands that demonstrate
> configuration that is not generating a set of triples you need in the
> compat tree. Will that set be generated with a solution I provided in
> the previous email?
>
> If we can get these samples, I'm sure it will be easy for Pavel to
> provide SSSD fix as well, and these samples can be then used to generate
> a test cases to prevent possible regressions in future.
>
>>
>> On Nov 13, 2017, at 4:25 AM, Pavel Březina
>> <pbrez...@redhat.com<mailto:pbrez...@redhat.com>> wrote:
>>
>> Can you send us some example of what you are trying to achieve and what
>> does not work? I'm also ccing Alexander Bokovoy to see why IPA adds
>> somewhere dash and somewhere blanks.
>>
>
> --
> / Alexander Bokovoy
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
