Hi guys, I spent some time working at this ticket
https://fedorahosted.org/sssd/ticket/1108 and I think it's finally
ready to be reviewed by others.
Description of the problem and scope of the changes can be found in
the commit message. I also wrote some unit tests but the patch is a
quite long already so I think it would be better to send the tests as
an another patch. Or should I create a patch for each modified file?
Package sssd_188.8.131.52-1 on Debian FTBFS for mips and mipsel.
dyndns_test_ok is failing with following log:
[ RUN ] dyndns_test_ok(Tue Jul 8 15:53:55:004476 2014) [sssd] [be_nsupdate_args] (0x0200): (Tue Jul 8 15:53:55:004521 2014) [sssd] [child_handler_setup] (0x2000): nsupdate auth type: GSS-TSIGSetting up signal handler up for pid (Tue Jul 8 15:53:55:004693 2014) [sssd] [__wrap_execv] (0x0200): nsupdate success test case(Tue Jul 8 15:53:55:004825 2014) [sssd] [__wrap_execv] (0x1000): Child exiting with status 0(Tue Jul 8 15:53:55:005275 2014) [sssd] [child_handler_setup] (0x2000): Signal handler set up for pid (Tue Jul 8 15:54:55:837623 2014) [sssd] [write_pipe_handler] (0x0020): write failed [Broken pipe].(Tue Jul 8 15:54:55:837801 2014) [sssd] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete(Tue Jul 8 15:54:55:837869 2014) [sssd] [nsupdate_child_stdin_done] (0x0040): Sending nsupdate data failed : Broken pipe(Tue Jul 8 15:54:55:837947 2014) [sssd] [be_nsupdate_done] (0x0040): nsupdate child execution failed : Dynamic DNS update failed(Tue Jul 8 15:54:55:837985 2014) [sssd] [dyndns_test_ok] (0x1000): Child request returned : Unknown error 14321582280x555d0014 != 0../src/tests/cmocka/test_dyndns.c:222: error: Failure![ FAILED ] dyndns_test_okChild part has finished before the child handler was created.
I have created and attached a patch which is workaround for this issue.
Could someone please take a look and comment this?
one of our users ran into an interesting problem -- her AD
infrastructure was different from the DNS server. Because by default, we
perform update against the server we're connected to, the DNS update
Per Simo's suggestion, I've implemented a new option that allows the
administrator to override the DNS server used for DNS updates.
we talked about implementing ticket #2509 with Pavel in person, but it
would be nice to see if other other developers agree before all the code
is written :-)
The design page is here:
For your convenience, the text of the design page is also copied below:
= Mapping Proxy ID provider names to Kerberos principals =
=== Problem statement ===
Some users are migrating to SSSD from a legacy configuration that consisted
of a traditional UNIX user stored in `/etc/passwd` and managing their
Kerberos tickets either with the use of some GUI tool or just command-line
`kinit`. While these users can use SSSD by configuring the `id_provider`
proxy, very often the name of their UNIX user is different from the name
of their company-wide Kerberos credentials.
This feature helps the above use-case by mapping their UNIX user name to
the Kerberos principal name.
=== Use cases ===
Joe User has a company laptop where his UNIX user has been traditionally
named `joe`. At the same time, his company Kerberos principal is called
`juser(a)EXAMPLE.COM`. Joe would like to start using SSSD to leverage
features like offline kinit without having to rename his UNIX user and
chown all his local files to the corporate user ID.
=== Overview of the solution ===
The Kerberos provider will acquire a new option that describes how are the
user names from the ID provider mapped onto the user part of the Kerberos
principal. The user would then add the appropriate mapping to the `domain`
section of `sssd.conf`.
=== Implementation details ===
A new option `krb5_map_user` would be added to the Kerberos auth code. This
option would have form similar to how we map the LDAP extra attributes,
that is `local_name:krb5_name`. When mapping exists for the user who
is authenticating, the krb5_auth module would use that user name for
calls like `find_or_guess_upn` instead of `pd->name`. We should consider
whether to keep using `pd->name` or introduce another attribute to the
=== Configuration changes ===
A new configuration option tentatively called `krb5_map_user` would be
added. This option is unset by default, which means whatever user name
the ID provider stores will be used.
=== How To Test ===
1. Prepare a Kerberos KDC, add a user principal (`juser(a)EXAMPLE.COM`)
1. Add a local user using `useradd` with name that differs from
Kerberos principal in the name portion. (`joe`)
1. Configure SSSD with `id_provider=proxy` with `proxy_lib_name=files`
and `auth_provider=krb5` pointing to our test KDC
1. Attempt to authenticate using a PAM service. The authentication
should fail and the logs would show authentication as `joe(a)EXAMPLE.COM`
1. Set `krb5_map_user` to `joe:juser` and restart SSSD.
1. Authenticate again. This time, authentication should succeed and the
user's klist output should list `juser(a)EXAMPLE.COM`. The `id(1)` output
should still list `joe`, though.
1. Test that Kerberos ticket renewals still work
1. Test that delayed kinit still works.
=== Authors ===
* Jakub Hrozek <jhrozek(a)redhat.com>
First three patches introduce changes to collection that were needed for
the implementation of the INI object modification API
The rest are for the INI itself. I made recommended changes and cleaned
doxygen comments a bit.
The INI interface so far does not include:
a) Saving to file - function requested by Pavel
I plan to provide this functionality in the follow up patches.
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
kindly see the attached patch and the commit message. I'm fine with
merging the patch after we branch 1-12 and master but I didn't want to
forget to remove this obsolete code while I'm looking at the resolver
I have take the following tikcet that is about implementing D-Bus calls
for domains, users and groups. I have some questions.
*List and Find methods interface*
At this moment we implement all List* and Find* methods on
/org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces
on /path and /path/*, therefore we can implement the methods as:
/infopipe/Users/$UID user specific methods and properties
/infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
The interface from the design page is already implemented. Is there any
method or property that is missing?
Do we want also to have methods ListDomainUsers() and ListUsers()
without the name filter?
Do we want some other filter options as well?
Should extraAttributes be present in Properties.GetAll() output?
What is UpdateGroupList() supposed to do?
Property groups - do we really want to return list of object paths
instead of pure group names? I think that more common use case will want
only the names. Or we can even implement both.
Basically the same questions and per Users.
Attached are patches that perform changes in the monitor process and the
low-level sbus and sysdb code required to run the NSS responder as a
non-privileged user. Some of the patches call chmod/chown on files owned
by the SSSD, so I'd like to request a very careful review.
The patches depend on patches from threads:
* SSSD: Add the options to specify a UID and GID to run as
* Packaging fixes related to non-root SSSD
I tried to explain the changes well in the commit messages. See below
for some more and especially questions.
[PATCH 1/7] SSSD: Load a user to run a service as from configuration
Pretty much just loads the sssd user from configuration and stores the
uid/gid. One question -- should the individual services or domain have a
option to ignore the sssd user? For instance:
user = sssd
group = sssd
# Would run as SSSD
# Would run as root/whatever user monitor runs as
ignore_sssd_user = True
This would mostly be a fallback for cases where we introduce a bug. I
don't think this kind of granularity is needed, the user can just
run sssd as root completely:
user = root
group = root
[PATCH 2/7] SBUS: Chown the sbus socket if needed
Chowns the monitor sbus socket if a non-root sssd user is specified. I
don't think we allow more privileges than before, the monitor socket has
permissions 0600 and is owned by sssd.sssd, so only the private user and
root (who bypasses DAC checks anyway) can access it.
In sbus_new_server(), we can open the socket after dbus creates it and
call fchmod() and fchown() to avoid some kind of TOCTOU races. But I'm
not sure this is needed given that a privileged process will create the
[PATCH 3/7] SBUS: Allow connections from other UIDs
A simple patch, allows connections from the sssd user. Please see the
commit message for more details.
This patch (and the previous) should have a unit test, but currently our
sbus tests are tightly tied to the check framework. I need to change the
common code to be test framework-agnostic, but I don't want to delay the
inclusion of these patches.
[PATCH 4/7] BE: Own the sbus socket as the SSSD user
Same as the two previous patches, just for the sssd_be process.
[PATCH 5/7] MONITOR: Allow confdb to be accessed by nonroot user
Confdb is created by the privileged monitor process, but needs to be
accessed by nonprivileged responder processes. chown it after creation.
[PATCH 6/7] SYSDB: Allow calling chown on the sysdb file from monitor
Same as the previous one, just for the sysdb.
[PATCH 7/7] NSS: Run as a user specified by monitor
With this patch, it's possible to run the NSS responder as a