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.
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
for past few days, I've been working on python3-compat patch for sssd. The patch  is attached to the issue that requests this feature .
- The patch tries to maintain backward compatibility for Python 2.6 and 2.7 - I admit I only tested 2.7 so far, but it seemed to work ok.
- I didn't yet solve the build part - for now, I just handedit configure.ac to set "PYTHON=python3" and src/external/python.m4 to set "AC_PATH_PROG(PYTHON, python3)" and compile with that.
- I managed to run Python tests in src/tests except python-test.py itself (it says "OSError: [Errno 5] Could not initialize connection to the confdb" and I didn't yet investigate why that happens).
- To run tests, one must modify the hashbangs to /usr/bin/python3 (I now see that I left one of these in the actual patch, so please disregard that).
I'd like to ask you, sssd devels, to give me some comments on the patch (or ask questions) and if you have some time to spare, doing more extensive testing would also be very welcome.
Bohuslav "Slavek" Kabrda.
While checking if our custom signal handlers properly handle errno, I
stumbled on a few cleanups, they are attached.
turns out our few signal hanlders are errno safe, and tevent signal
handling function is also fine.
Simo Sorce * Red Hat, Inc * New York
I noticed that if using simple access provider and having non-existing
group or user in access/deny list then access will be denied and "su:
System error" will be printed.
I think it's OK to simply skip non-existing objects on allow_list.
I'm not so sure what to do in case of deny lists. Should we also just
skip them or should we deny the user and print more appropriate message
("su: Permission denied")?