While looking at another issue I realized that we used a wrong
formatting conversion for UID/GID values - %d. For very large values,
there were sometimes overflows (-1) in the DEBUG logs. The attached
patch converts the format specifier to PRIu32 as the value we print is
I'm fine with pushing this patch atop Nikolai's patches so that we don't
make him rebase the large patchset again.
as we discussed with the other developers earlier this week, we should
start using Reviewed-by tag. As a benefit, we would easily see which
developer understands the code apart from the author without having to
resort to searching the mailing list.
I tried using the tag when pushing Pavel's recent patch reviewed by
Stephen, so you can see the result with:
git log -1 fd520622529e26682eb8fa4c5355db18399c3121
For the workflow, I followed the Samba guidelines pretty much
Would this workflow work for everybody?
Also, do we gain anything by using Signed-off-by as well? I think we
wouldn't as the vast majority of patches are written by a single
contributor, so adding Signed-off-by would be mostly busywork, but I'd
like to hear other opinions.
When we agree on the workflow, we should add it to:
I'm working on a VPN server that among others it needs to authenticate
users. Since there are various backends that may store users, and PAM
provides a module to access them all, I currently use a privileged
process to perform PAM authentication for the users.
However, PAM is pretty good for interactive password authentication, but
it doesn't look like it was designed to handle public keys/certificates
and its API does not provide a way to obtain any additional information
for the user (e.g., keys, certificates). Thus my server has to handle
certificate authentication separately from passwords. However, as I
understand from the SSSD code it has support for backends that could
store certificates. So the question is, whether my server could
benefit, if it uses sss directly instead of PAM? Does sss provide a
library for authentication? If such usage of sss would be possible do
you see any additional advantages (or disadvantages)?
(The scenario that the vpn server would benefit, is the case where a
user connects using TLS-client authentication, and the server -if it
could obtain the client's public key from SSS- it would verify the
client without any need for PKI).
> On Thu, Jan 30, 2014 at 02:35:57PM +0400, Denis Kutin wrote:
> > Dear friends,
> > Using sssd, for a long time, I have come across with a problem recently,
> > which I would like to solve with your help.
> > I provide centralized authentication and authorization service for a huge
> > heterogeneous network. And in my case it would be "nice and easy" if sssd
> > used only shells(5). I believe this mechanism is sufficient for
> > identification of an allowed shell.
> > I take a liberty to offer you this tiny patch, which will let use
> > (*) in param allowed_shells in sssd.conf
> > What do you think about it?
> the patch itself looks OK except for lines being over 80 characters,
> but I don't think I understand the use case well. If a user has a shell
> specified that is outside /etc/shells he's kicked out anyway. If he does,
> he's permitted by default..
Not exactly. SSSD has a shell_fallback If user has a shell specified that
is outside of /etc/shells, SSSD checks allowed_shell parameter. If user's
shell is in allowed_shell, then SSSD fallback to shell_fallback, otherwise
user kicked out.
Here, from sssd.conf(5)
1. If the shell is present in "/etc/shells", it is used.
2. If the shell is in the allowed_shells list but not in
"/etc/shells", use the value of the shell_fallback parameter.
3. If the shell is not in the allowed_shells list and not in
"/etc/shells", a nologin shell is used.
At this moment I need to generate sssd.conf dynamically, specified all
existed (in our environment) shells.