RFC: Socket-activation, some changes in the architecture.
by Fabiano Fidêncio
People,
Recently I've faced some issues when testing the socket-activation
working running as sssd-user, which will force me to take a different
path for a few things and I really would like to know your opinion on
those things.
So, currently, this is what the nss.service looks like:
[Unit]
Description=SSSD NSS Service responder
Documentation=man:sssd.conf(5)
After=sssd.service
BindsTo=sssd.service
[Install]
Also=sssd-nss.socket
[Service]
ExecStartPre=-/bin/chown @SSSD_USER@:@SSSD_USER@ @logpath(a)/sssd_nss.log
ExecStart=@libexecdir@/sssd/sssd_nss --debug-to-files --unprivileged-start
Restart=on-failure
User=@SSSD_USER@
Group=@SSSD_USER@
PermissionsStartOnly=true
As you probably noticed, I've been using systemd's machinery to change
the debug files' owner and to start the responder by the proper user
(sssd or root). Well, it doesn't work that well as expected as systemd
ends up calling initgroups(sssd, ...) in order to start any service
using "sssd" user and this call is done _before_ starting the NSS
responder, which will hang for the "default client timeout" (300s).
Okay, we have to change it and here is where I need your help!
- Adding a new "sssd-user" option:
By adding this option we could just start the responders calling:
libexecdir@/sssd/sssd_nss --debug-to-files --sssd-user=@SSSD_USER@.
The unit file would be changed a little as the ExectStartPre, User and
Group options could just go away.
The server code would be changed a little in order to invoke
setenv("_SSS_LOOPS", "NO", 0) earlier, as done here:
index 52e6ed7..013e572 100644
--- a/src/util/server.c
+++ b/src/util/server.c
@@ -461,8 +461,6 @@ int server_setup(const char *name, int flags,
char *locale;
int watchdog_interval;
- setenv("_SSS_LOOPS", "NO", 0);
-
ret = chown_debug_file(NULL, uid, gid);
if (ret != EOK) {
DEBUG(SSSDBG_MINOR_FAILURE,
@@ -481,6 +479,8 @@ int server_setup(const char *name, int flags,
return ENOMEM;
}
+ setenv("_SSS_LOOPS", "NO", 0);
+
/* To make sure the domain cannot be set from the environment, unset the
* variable explicitly when setting up any server. Backends later set the
* value after reading domain from the configuration */
Also, the server_setup() would receive the user passed to --sssd-user
and perform a getpwnam() in order to get the uid/gid and then be able
to change debug files' owner and become the user, as done here:
diff --git a/src/util/server.c b/src/util/server.c
index c9a2726..d9da803 100644
--- a/src/util/server.c
+++ b/src/util/server.c
@@ -445,6 +445,7 @@ static const char *get_pid_path(void)
int server_setup(const char *name, int flags,
uid_t uid, gid_t gid,
+ char *sssd_user,
const char *conf_entry,
struct main_context **main_ctx)
{
@@ -463,6 +464,22 @@ int server_setup(const char *name, int flags,
setenv("_SSS_LOOPS", "NO", 0);
+ if (sssd_user != NULL) {
+ struct passwd *pw;
+
+ pw = getpwnam(sssd_user);
+ if (pw == NULL) {
+ DEBUG(SSSDBG_MINOR_FAILURE,
+ "Cannot get the information about the user %s. "
+ "The process will be run as root\n", sssd_user);
+ uid = 0;
+ gid = 0;
+ } else {
+ uid = pw->pw_uid;
+ gid = pw->pw_gid;
+ }
+ }
+
ret = chown_debug_file(NULL, uid, gid);
Okay, okay. It would work. Would it be okay for the rest of the developers?
Considering that it will be okay ... doesn't it look a little bit
weird/inconsistent passing the sssd-user sometimes and passing the
uid/gid in the most part of the times? Wouldn't be better just pass
the sssd-user all the time and do the getpwnam() call here instead of
doing it in the monitor when starting it?
Now, considering we will user "--sssd-user" when calling the
responders ... I can take advantage of this in case we _only_ use this
option when socket-activating the responders, as the responder will
know from the beginning whether it was socket activated or explicitly
started (and it's useful for shutting down the responder when it's
inactive). Another option (that I personally prefer) is having, again,
a new option "--socket-activated" that would make things clear for
whoever ends up taking care of this code later on (probably the future
me). Would that be okay?
So, summing up the questions ...
- Is there any problem on calling 'setenv("_SSS_LOOPS", "NO", 0)'
earlier in the process?
- Would be okay adding "--sssd-user" option for starting the responders?
- Shall I get rid of the "--uid and --gid" options in order to only
use the new added "--sssd-user" one?
- Shall I add a new "--socket-activated" option for starting the
responders or just abuse the "--sssd-user" one?
Looking forward to hearing your opinions!
Best Regards,
--
Fabiano Fidêncio
7 years, 3 months
radius authentication through sssd
by Vijayakumar Kannan
Greetings,
OS running on rhel7.3 platform using sssd integrated with AD authentication is working as expected. In my environment I have OTP (one time password) server on radius solution. How do I use the SSSD to forward the authentication to radius server for ssh authentication?
Also how I can enable 2 step password prompt 1st prompt for AD validation and 2nd prompt for OTP validation(radius)?
Regards,
Vijay
Qatar Airways - Going Places Together
Disclaimer:- This message (including attachments) is intended solely for the addressee named above. It may be confidential, privileged, subject to copyright, trade secret, or other legal rules and may not be forwarded without the author's permission. If you are not the addressee you must not read, copy or disseminate this message. If you have received it in error please notify the sender immediately and delete the message from all storage devices. Any opinions expressed in this message do not necessarily represent the official positions of Qatar Airways. Any agreements (including any warranties, representations, or offers) concluded with Qatar Airways by using electronic correspondence shall only come into existence if an authorized representative of Qatar Airways has explicitly approved such contract formation. To the fullest extent permissible by law, Qatar Airways disclaim all liability for loss or damage to person or property arising from this message being infected by computer virus or other contamination.
7 years, 3 months
RFC: Configuration of trusted domain (a.k.a. subdomain) in sssd.conf
by Michal Židek
Hi,
for IPA provider, we plan to add the ability to configure
trusted domains (currently AD domains) in a similar way the
main domain is configured in sssd.conf.
If ipadomain.test is the main IPA domain and addomain.test
is the AD domain and there is IPA-AD trust extablished between
the two, I think the way to configure addomain.test specific
option could be:
[domain/ipadomain.com]
# the usual main domain configuration
[domain/ipadomain.com/addomain.com]
# configuration of trusted domain
So, the main domain would be used as prefix in the
section name where the trusted domain / subdomain
is configured.
I wanted to ask what other developers think about the
format. Note that not all options that are available
in the main domain will be available for the subdomain.
Michal
7 years, 3 months
[sssd PR#89][opened] nss: rewrite nss responder so it uses cache_req
by fidencio
URL: https://github.com/SSSD/sssd/pull/89
Author: pbrezina
Title: #89: nss: rewrite nss responder so it uses cache_req
Action: opened
PR body:
"""
Given the size of the current nss responder it was quite impossible
to simply switch into using the cache_req interface, especially
because most of the code was duplication of cache lookups.
This patch completely rewrites the responder from scratch. The amount
of code was reduced to less than a half lines of code with no code duplication,
better documentation and better maintainability and readability.
All functionality should be intact.
*Code organization*
All protocol (parsing input message and send a reply) is placed
in nss_protocol.c. Functions that deals with creating a reply
packet are placed into their specific nss_protocol_$object.c files.
All supported commands are placed into nss_cmd.c. Functions that
deals with cache req are in nss_get_object.c and nss_enum.c.
*Code flow for non-enumeration*
An nss_getby_$input-type is called for each non-enumeration command.
This function parses the input message, creates a cache_req_data
structure and issues nss_get_object that calls cache_req. When
this request is done nss_getby_done make sure a reply is sent to
the client.
*Comments on enumeration*
I made some effort to make sure enumeration shares the same code
for users, groups, services and netgroups. Netgroups now uses
nss negative cache instead of implementing its own.
*Unit tests*
ALl existing unit tests, including the one for nss responder, pass.
@mzidek-rh is going to write new unit tests for added functionality
into cache_req and sss_ptr_hash interface.
Thanks to @spbnick for doing the first round of review, focused on
code documentation and readibility.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/89/head:pr89
git checkout pr89
7 years, 3 months
[sssd PR#116][opened] intg: Generate tmp dir with lowercase
by fidencio
URL: https://github.com/SSSD/sssd/pull/116
Author: lslebodn
Title: #116: intg: Generate tmp dir with lowercase
Action: opened
PR body:
"""
This is a workaround for buggy python-requests 2.12.4.
It cannot handle uppercase letters in file path.
The manual page MKTEMP(1) says that the parameter --dry-run is unsafe.
It is not critical for our use-case in CI but we should revert the patch
after fixed version of puython-request will be released
The broken version of python-requests (2.12.4) is in fedora rawhide and debian testing +
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/116/head:pr116
git checkout pr116
7 years, 3 months
