fd leak in sssd_pam
by Jan Engelhardt
Hej,
I am noticing an fd leak with the /usr/lib/sssd/sssd_pam helper program
(affected versions: 1.4.1--1.5.11). As is usual with weird bugs, this
happens on one machine while it does not on another, but it at least it
is reproducible on the one :)
What I observe is that for every authentication attempt (may either
fail or success), an fd is left behind::
17:25 mailsrv:/proc/31491/fd # ls -l
[...]
lrwx------ 1 root root 64 Jul 28 17:25 42 -> socket:[228511]
lrwx------ 1 root root 64 Jul 28 17:25 43 -> socket:[227514]
lrwx------ 1 root root 64 Jul 28 17:25 44 -> socket:[228537]
lrwx------ 1 root root 64 Jul 28 17:21 5 -> anon_inode:[eventpoll]
lrwx------ 1 root root 64 Jul 28 17:21 6 -> anon_inode:[eventpoll]
lr-x------ 1 root root 64 Jul 28 17:21 7 -> pipe:[213086]
lrwx------ 1 root root 64 Jul 28 17:21 76 -> socket:[220069]
l-wx------ 1 root root 64 Jul 28 17:21 8 -> pipe:[213086]
lrwx------ 1 root root 64 Jul 28 17:21 88 -> socket:[221781]
lrwx------ 1 root root 64 Jul 28 17:21 9 -> anon_inode:[eventpoll]
17:25 mailsrv:/proc/31491/fd # su - jengelh
17:25 mailsrv:~ > su - jengelh
Passord:
17:25 mailsrv:~ > logout
17:25 mailsrv:~ > logout
17:25 mailsrv:/proc/31491/fd # ls -l
[...]
lrwx------ 1 root root 64 Jul 28 17:25 42 -> socket:[228511]
lrwx------ 1 root root 64 Jul 28 17:25 43 -> socket:[227514]
lrwx------ 1 root root 64 Jul 28 17:25 44 -> socket:[228537]
lrwx------ 1 root root 64 Jul 28 17:25 46 -> socket:[227688]
[...]
Furthermore, this new socket has no complementary process to have
the other end of socket:[227688] open (anymore):
17:30 mailsrv:/proc # ls -l */fd/* | grep socket:.227688
ls: cannot access 7175/fd/3: No such file or directory
ls: cannot access self/fd/255: No such file or directory
lrwx------ 1 root root 64 Jul 28 17:25 31491/fd/46 -> socket:[227688]
lsof(8) tells us the name part of the socket for reference:
sssd_pam 31491 root 46u unix 0xffff88001083a840 0t0 227688 /var/lib/sss/pipes/private/pam
12 years, 9 months
[PATCHES] First stage of the refcount support
by Jan Zelený
Because I'll be on my vacation for two weeks starting tomorrow, I'm sending
patches which outline how could the reference counter look like.
Patches depend on some of my previously sent optimization patches.
Please note that these patches don't optimize or change anything yet, they
just add the reference counter and make it work (i.e. it contains sane
values).
Feel free to comment, I'll read your comments after the vacation.
Thanks
Jan
12 years, 9 months
SSSD host access behavior similar to /etc/ldap.conf groupdn in pam_ldap
by DeMarco, Dennis
I am trying to switch over from pam_ldap to use sssd authentication.
I have host based access based on a static ldap group and use the pam_groupdn attribute in /etc/ldap.conf to restrict access to hosts. I can not seem to replicate this behavior in SSSD. I have tried every combination of ldap_access_filter to no great success.
I do not have Memberof plugin in the old style Fedora DS 1.0.4. Is there a way for SSSD to use this style of host base authentication? I rather not go with a sssd/pam_ldap hybrid in system-auth.
Thanks,
Dennis
Example of my old setup for reference:
/etc/ldap.conf
Pam_groupdn cn=test,ou=LoginGroups,dc=example,dc=com
Example of the group ldiff
dn: cn=test,ou=LoginGroups,dc=example,dc=com
uniqueMember: uid=user1,ou=People, dc=example,dc=com
uniqueMember: uid=user2,ou=People,dc=example,dc=com
objectClass: top
objectClass: groupofuniquenames
cn: test
description: test account group
-----------------------------------------
The information contained in this e-mail message is intended only
for the personal and confidential use of the recipient(s) named
above. This message may be an attorney-client communication and/or
work product and as such is privileged and confidential. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and
that any review, dissemination, distribution, or copying of this
message is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and
delete the original message.
12 years, 9 months
Authenticating users who exist in multiple domains
by Michael Fenn
Greetings,
We're currently in the process of evaluating RHEL6 and as part of that
process, we're investigating using SSSD in our environment. In the
process, we've hit a little snag when it comes to authenticating users
who exist in multiple domains.
First, a little background. We have two groups of users, each
authenticating against a different Kerberos domain. However, both users
exist in the same LDAP directory. As such, I've set up SSSD with two
domains, both with the same LDAP directory provider but with different
Kerberos authentication providers. Let's call them A and B. The domains
key in my sssd.conf is set to A,B .
If a user X in domain A attempts to authenticate either as X or X@A,
everything works as expected. Similarly, if a user Y in domain B
attempts to authenticate as Y@B, everything works. However, if Y is not
able to authenticate as simply Y .
In essence, it seems that if authentication fails for the first domain,
then SSSD will not attempt to authenticate the user against any other
domains. For us, this represents a regression from the old way of doing
things, i.e. pam_krb5, where such failover was possible. Are there any
plans to change this behavior in SSSD?
Thanks,
Michael Fenn
Systems Administrator
Research Computing and Cyberinfrastructure
Penn State
12 years, 9 months
[PATCH] prevent segfault when ldap_uri is misconfigured
by Jakub Hrozek
https://fedorahosted.org/sssd/ticket/911
[PATCH 1/2] Do not add a NULL host parsed from LDAP URI
Do not add a server into fail over in case its host name is NULL. Also
fixes a possible memleak in case be_fo_add_server() failed.
[PATCH 2/2] Only print server address if one is available
The second patch is kinda related. In fail over, it is possible that
fo_get_server_hostent() returns NULL in case we did not find any name
for the server. Therefore we must check its return value before
dereferencing it.
12 years, 9 months
[PATCH] fo_get_server_name() changes
by Jakub Hrozek
Attached are two more-or-less cosmetic changes.
The current fo_get_server_name() always returns a string, and for
example, if the name is not set, it returns "unknown name". While this
is handy is cases like debug printing, I think that there should be a
more low-level function that would just return NULL for no name set.
[PATCH 1/2] Rename fo_get_server_name to fo_get_server_str_name
I think this name better reflects the nature of the function
[PATCH 2/2] fo_get_server_name() getter for a server name
This new function returns the host name if set and NULL otherwise. It is
much handier in tests (see the src/tests/fail_over-tests.c hunk for
example). It also allows us to be more defensive in the resolve
callbacks where it is no longer possible to construct an URI like
'ldap://"unknown server"', we would rather get an error message instead.
12 years, 9 months
Re: [SSSD] [PATCH] Fix python HBAC bindings for python <= 2.4
by Alexander Bokovoy
Hi Jakub,
(sorry for breaking the thread, I forgot to subscribe to the list
earlier and thus got no reference to the thread).
I would NACK the patch. Few issues:
1. char *str_concat_sequence(PyObject *seq, char *delim) use is always
with constant delim, it would make sense to change the signature to
follow it.
2. discard_const_p() for Python 2.4 is a bit too wide use as it weakens
2.6 (and 3.0) API usage. What if you make a simple wrapper on top of
discard_const_p() that is ident to it for 2.4 but returns the actual
value without type conversion for other cases.
Something like this:
#if PYTHON_2_4
#define sss_py_const_p(type, value) discard_const_p(type, (value))
#else
#define sss_py_const_p(type, value) (value)
#endif
3. hbac_rule_set_enabled() currently is too strict, it accepts only
Python's boolean. In FreeIPA LDAP backend returned values are strings so
we'll have to build up a wrapper on top of pyhbac. What about be more
flexible and accepting what FreeIPA's Bool parameter type accepts:
('truths', frozenset, frozenset([1, u'1', u'true', u'TRUE'])),
('falsehoods', frozenset, frozenset([0, u'0', u'false', u'FALSE']))
This would be needed only for setter, getter would always give out PyBool.
Please split the patch into two -- compatibility fixes and API improvements.
Thanks in advance,
--
/ Alexander Bokovoy
12 years, 9 months