[PATCH] Convert krb5_kdcip option to krb5_server
by Jan Zelený
Based on Jakub's proof-of-concept patch I prepared a patch which handles this
option replacement. As it was discussed on the meeting couple weeks back, I
didn't modify the update script (I hope I remember this requirement
modification right) and in case both krb5_kdcip and krb5_server options are in
the config file, the latter one has bigger priority.
Jan
13 years, 1 month
[PATCH] Save dummy groups to cache during initgroups (master)
by Jakub Hrozek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[PATCH 1/2] sysdb interface for adding fake groups
Adds a sysdb_add_fake_group() call that adds an expired group entry.
Also tweaks the NSS code a little so the fake group entries that are
invalid are skipped. This is not how we use the fake groups in patch #2
as we also store the gid, but I think it's worth making sure we don't
return fake groups now that we have a mechanism to add them.
[PATCH 2/2] Save dummy groups to cache during initgroups
When performing initgroups/getgrouplist on RFC2307, add fake group
entries for those groups that are not cached already. That way, complete
group membership is returned without saving complete group objects.
These two patches apply to master only but I have a 1.2 counterpart -
currently only in my fedorapeople repo - I can resend them when/if these
are approved as these read much easily, so I think it makes sense to
review them first.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkykhNMACgkQHsardTLnvCVyDgCgqOgmne9qYk9l1uEyB32mJWn5
LQcAnRNErXrbmwHVY49Gx5IANUF946dr
=O6nl
-----END PGP SIGNATURE-----
13 years, 1 month
[PATCH] Create kdcinfo files for the LDAP provider
by Jakub Hrozek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This series of patches implement creation of kdcinfo files when GSSAPI
is used with pure LDAP provider.
[PATCH 1/4] Add KDC to the list of LDAP options
A simple patch that adds a way to specify the KDC
[PATCH 2/4] Report Kerberos error code from ldap_child_get_tgt_sync
While looking at the ldap_child code, I noticed that the call to
ldap_child_get_tgt_sync should return the Kerberos specific error code
rather than errno.
[PATCH 3/4] Make ldap_child report kerberos return code to parent
The buffer used to communicate between parent and child now contains a
new parameter which is the Kerberos error code. An example of use of
this is detecting that KDC was unreachable in the following patch.
[PATCH 4/4] Initialize kerberos service for GSSAPI
I'm not very fond of patch #4 myself - the reason is that as far as I
remember, the sdap_ modules were meant to be a rather thin wrapper to
provide an "async set of LDAP calls", the provider and backend-specific
calls belong one level up, to the ldap_ modules. However, in order to
support fail over in during sdap_kinit_, I used the be_resolve_ family
functions there, which looks like breaking the abstraction level quite a
bit. If there are any suggestions on how to accomplish the kinit w/ fail
over better, I'll be glad to hear them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyGK/UACgkQHsardTLnvCX1eACgvWrKscnQpQaUFMBZg5idClEM
lboAmgIdqQDlgenJCkELWL98jPK0yvog
=3NiP
-----END PGP SIGNATURE-----
13 years, 1 month
[PATCHES] Support for netgroups in the NSS client and responder
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
These patches were tested on the local domain (by manually editing the
sssd.ldb). I also ran them through valgrind.
Patch 0001: Add utility function sss_strnlen()
This is useful for guaranteeing the size of an input buffer. I'm using
this in the nss client portion of the netgroups support.
Patch 0002: Store entry_cache_timeout in sss_domain_info object
This is useful so that the NSS responder can identify an domain's
entry timeout for expiring the memory cache for a lookup such as
with netgroups.
Patch 0003: Require explicit setting of callback context for check_cache
Previously, it was implicitly using the nss_dom_ctx, but there are
situations where we would want to send a different private context.
Specifically, we need to be able to send a step_ctx for the netgroups
support in patch 0010.
Patch 0004-0005: Sysdb interfaces for netgroups (and associated tests)
These are identical to the last set I sent in the "Sysdb interface for
netgroups" thread. I am retiring that thread to use this one for the review.
Patch 0006: Rename group.c and passwd.c for clarity
Prefixing group.c and passwd.c with "nss_" similar to the way the
PAM client sources are prefixed with "pam_". This patch isn't strictly
necessary, but I wanted it to be more clear which files were associated
with NSS vs. PAM vs. common in the sss_client directory. Patch 0007 will
create nss_netgroup.c as well.
Patch 0007: Add support for netgroups to NSS sss_client
There's one peculiarity about this patch that I have to note. I need to
send back a true/false value to the setnetgrent call in order to
properly report that there were no entries. This differs from the other
set*ent functions because we are processing a specific requested entry
rather than enumerating all entries. Without doing this, we actually
return a netgroup containing no member triples, which is certainly not
what the client app expects.
Patch 0008: Add negative cache features for netgroups
This patch just updates the negative cache interface to allow including
netgroups in the negative cache like other entries.
Patch 0009: Split out some helper functions for the NSS responder
Create a new private header and make some functions available for
other object files. The nsssrv_cmd.c file is getting far too large to be
manageable. Patch 0010 will create a separate file (nsssrv_netgroup.c)
to hold all of the netgroup-related code, but we need access to this set
of functions in both places.
Patch 0010: Add netgroup support to the NSS responder
This is the big one. It borrows a lot of its design from the recently
rewritten enumeration code, but it has a few gotchas (notably that we
need to maintain state between setnetgrent and getnetgrent calls to
ensure that we are still answering requests for the same requested entry.
Remaining work on netgroups will be to add support for the LDAP backend
to store the netgroups in the cache appropriately. In the future
(https://fedorahosted.org/sssd/ticket/630) we will also add netgroups
support to the proxy provider. This proxy support is not planned for 1.4.0.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyakSUACgkQeiVVYja6o6Or5ACgrYx+rlk4ux/MOCjqVQ9Ds8+6
BvQAn1KrVnr7J0HAreUTovg8B03WLp0R
=71HE
-----END PGP SIGNATURE-----
13 years, 1 month
Behaviour of getgrnam/getgrgid
by Ralf Haferkamp
Hi,
Is it really the intended behaviour of the sssd LDAP backend (I am
running the current code from the master branch) to only return the group
members that are already cached in sysdb and to silently ignore
everything else? E.g. when I start sssd with empty caches and do a
"getent group <random-ldap-group>" I will only get back the group without
any members. Somehow I think this can't be intended :)
I have started working on a patch to let sssd look up the non-cached
users via LDAP (and save them into the cache). Find it attached. Note:
That patch is not really complete (e.g. it doesn't handle rfc2307 groups
correctly). But before putting more effort into this I like to make sure
that I am not trying to fix a "feature" here.
--
regards,
Ralf
13 years, 1 month
Man pages should mention supported providers
by Jan Zelený
Supported providers are mentioned in Description section, because there was
already partial description present. Another possibility was to comment it as
configuration option (e.g. create access_provider=ldap record there). I like
this way more, but I'm not sure whether it is descriptive enough.
--
Jan
13 years, 1 month
[PATCH] dhash: Allow hash_enter() to update entries
by Sumit Bose
Hi,
Patch 0003 add update capabilities to hash_enter(). The current
behaviour was to keep the old entry and return HASH_SUCCESS. I have
added an update test to the unit test. Maybe it make sense to update the
version number to make it easier to detect if updates are possible or
not.
Patch 0001 adds a missing include file and 0002 makes hash_example pass
valgrind without errors.
bye,
Sumit
13 years, 1 month
Handling nested netgroups (looking for recommendations)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
First, a little overview on netgroups. Netgroups in LDAP can contain two
attributes:
1) nistNetgroupTriple - Contains a literal triple of (host, username,
domain)
2) memberNisNetgroup - The name (or DN, more on that later) of another
netgroup.
Returning triples are simple, we just return them as-is. However,
returning nested netgroups introduces a bit of additional complexity.
Currently, nss_ldap just returns the name of the memberNisNetgroup
directly to glibc and allows it to handle it. This means that glibc will
make an extra, internal set of setnetgrent(), getnetgrent()
endnetgrent() calls to nss_ldap. Or not: the design of glibc means that
if the nested netgroup appears in an NSS provider listed in
nsswitch.conf before nss_ldap, it will be returned from there, rather
than nss_ldap. This means that it is theoretically possible for a local
file to override the centralized LDAP for a netgroup.
With SSSD, our original plan was that we should always treat the LDAP
server as authoritative. We would internally handle recursive lookups
for nested netgroups and unravel them ourselves before returning them to
glibc. We would only return nested names in this case if the specified
member does not exist on the LDAP server (in this case we will assume
that it's meant to be handled by another netgroup provider).
To illustrate the difference:
With nsswitch.conf:
netgroup files nss_ldap
On LDAP:
ldapnetgroup1: (user1, host1, ldapdomain) extranetgroup2
extranetgroup2: (user2, host2, ldapdomain)
In local files:
extranetgroup2: (localuser, localhost, localdomain)
With nss_ldap, making a request for ldapnetgroup1 would return to the
calling application (after glibc completed all its internal lookups):
ldapnetgroup1: (user1, host1, ldapdomain), (localuser, localhost,
localdomain)
Whereas with the proposed approach for SSSD:
With nssswitch.conf:
netgroup files sss
We would get back from glibc:
ldapnetgroup1: (user1, host1, ldapdomain), (user2, host2, ldapdomain)
So the difference in behavior should be clear now.
The obvious advantage to this approach is that the central server will
always be considered authoritative for its entries. We will assume that
the specified member should use the LDAP representation as its first
option, and fail over to glibc's lookup for other netgroup providers
only if it does not exist in LDAP.
This should provide a more stable environment, however it does differ
from the current expected behavior as defined by nss_ldap.
To enumerate the options we can follow:
1) We can behave exactly as nss_ldap does. If we locate a member
netgroup, we can return that directly to glibc and expect to have it
look it up as needed. Pros: identical behavior to the current state.
Cons: makes additional requests to the SSSD that we could be handling
internally without a lot of back-and-forth to glibc.
2) We can assume that member entries in LDAP refer to LDAP entries
unless we cannot locate them. In this case, we can internally handle the
recursive lookups to LDAP. Any member netgroups that we don't find in
LDAP should be returned to glibc to process. Pros: we can control
nesting limits this way. The memberOf plugin also does a good job with
protecting us against loops. We can parallelize the lookups of multiple
member netgroups for performance. Cons: we are changing the behavior as
described above.
Appendix) There is no formal specification of netgroups. It's possible
for the memberNisNetgroup attribute to contain either a simple name or a
full LDAP distinguished name. If a full DN is provided, we should assume
that this means that it must be in LDAP, and stop processing (and don't
return it) if we get a DN that doesn't match. For entries that are not
complete DN's, we should choose one of the two aforementioned approaches.
Please comment if you have an opinion.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyiMSIACgkQeiVVYja6o6MuxwCghVhG3baFori0Retl6itILvLe
NqkAn3Sn5EZkgP5Yoztuvh/KHudWP48S
=tcYu
-----END PGP SIGNATURE-----
13 years, 2 months
[PATCH] Save dummy member users during RFC2307 getgr{nam, uid} (master)
by Jakub Hrozek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[PATCH 1/2] sysdb interface for adding fake users
same as in previous patchset, just adds fake users
[PATCH 2/2] Save dummy member users during RFC2307 getgr{nam,uid}
When performing getgrnam/getgrgid, instead of looking up the member
users, just save expired user entries.
These patches apply on top of Ralf's patches. I also changed two very
minor things that IMHO make the whole codepath read more easily - I
moved struct sdap_process_group_state next to sdap_process_group_send()
and renamed sdap_process_group_done() as the name suggested that it is a
_done() callback of sdap_process_group_send().
Stephen, how would you like to coordinate backporting this to 1.2 since,
as far as I recall, we won't be backporting Ralf's patches?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkykhNsACgkQHsardTLnvCWBnwCgiJVOzgnJnN6riKU3SUrhhf7G
kq8AoKYyOhAz68ymJOSL2Pqfqhi2d4Xp
=I238
-----END PGP SIGNATURE-----
13 years, 2 months
[PATCH] Suppress some compiler warnings
by Sumit Bose
Hi,
some of the compiler flags used to build Fedora packages, e.g.
'-Wp,-D_FORTIFY_SOURCE=2' produces some extra warnings which were not
addressed so far. Except the ones for krb5_common.c in 0001 they are
cosmetics but might still irritate some people or tools.
bye,
Sumit
13 years, 2 months
