KRB5CCNAME variable broken in second concurrent login shell - bug?
by Joschi Brauchle
We have a weird problem with the KRB5CCNAME environment variable that
seems to be an SSSD bug.
Configuration:
------------ /etc/sssd/sssd.conf ------------
...
# Set CCache to Kerberos default
krb5_ccachedir = /run/user/%U
krb5_ccname_template = DIR:%d/krb5cc
...
------------ /etc/sssd/sssd.conf ------------
Now, user "ne96soh" logs in to the machine for the FIRST time and does a
kerberized ldapsearch:
------------
ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
DIR:/run/user/3036404/krb5cc
ne96soh@tueilnt-student01:~$ klist
Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
...
ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
... <succeeds>
------------
but then logs into the machine a SECOND concurrent time (i.e. leaving
first session open):
------------
ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
DIR::/run/user/3036404/krb5cc/tktZoweZq
ne96soh@tueilnt-student01:~$ klist
Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
...
ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (No
Kerberos credentials available)
------------
For me, the format of 'DIR::/run/user/3036404/krb5cc/tktZoweZq' in the
second login seems strange! Is this a valid format?
When I manuelly reset the KRB5CCNAME variable in the second login shell
to its original value 'DIR:/run/user/3036404/krb5cc', then the
ldapsearch using GSSAPI succeeds.
The reason of all this seems to be that SSSD reuses existing ccaches for
already logged on users, but possibly mixes up formats there.
See
------------ /var/log/sssd_default.log ------------
(Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [krb5_auth_send]
(0x4000): Ccache_file is [DIR::/run/user/3036404/krb5cc/tktZoweZq] and
is active and TGT is valid.
...
(Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [krb5_find_ccache_step]
(0x0080): Saved ccache DIR::/run/user/3036404/krb5cc/tktZoweZq if of
different type than ccache in configuration file, reusing the old ccache
...
(Wed Oct 15 14:04:54 2014) [sssd[be[default]]]
[safe_remove_old_ccache_file] (0x0400): New and old ccache file are the
same, no one will be deleted.
(Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [krb5_mod_ccname]
(0x4000): Save ccname [DIR::/run/user/3036404/krb5cc/tktZoweZq] for user
[ne96soh].
------------ /var/log/sssd_default.log ------------
Best regards,
--
Dipl.-Ing. Joschi Brauchle, M.S.
Institute for Communications Engineering (LNT)
Technische Universitaet Muenchen (TUM)
80290 Munich, Germany
Tel (work): +49 89 289-23474
Fax (work): +49 89 289-23490
E-mail: joschi.brauchle(a)tum.de
Web: http://www.lnt.ei.tum.de/
9 years, 4 months
[PATCHES] krb5: make krb5 provider view aware
by Sumit Bose
Hi,
this patchset makes the krb5 provider view-aware. All needed
functionality is in the 1st patch. 2nd makes sure the view data is only
update when there is a change and the 3rd makes a check in the
krb5_child more relaxed. This needed when the client gets a different
view and the UID of a user changes. In this case and old ccache cannot
be read by the user anymore and we should not fail in this case.
bye,
Sumit
9 years, 4 months
[PATCHES] SDAP: Refactor sdap_nested_group_hash_group
by Pavel Reichl
Hello,
please see attached patches.
1st patch adds unit test for sdap_nested_group_hash_group()
2nd patch refactors sdap_nested_group_hash_group()
While working on the test I found what I think may be a bug in
sdap_nested_group_hash_group()
Part of function definition consists of following:
int32_t ad_group_type;
...
ret = sysdb_attrs_get_int32_t(group, SYSDB_GROUP_TYPE, &ad_group_type)
ad_group_type is bitmask for AD group types and may contain
2147483648 (0x80000000)
(http://msdn.microsoft.com/en-us/library/ms675935%28v=vs.85%29.aspx)
which can't be stored in 32 bit integer.
In second patch I changed type of ad_group_type to uint32_t. But without
this change tests will fail because sysdb_attrs_get_int32_t() will
return ERANGE.
Thanks!
9 years, 4 months
[PATCH] AD: Never store case_sensitive as "true" to confdb
by Michal Židek
Hi,
Sumit noticed that one debug message in AD
ad_get_common_options may be misleading (it
informs about domain being set as case-insensitive
but do not mention if preserving feature is turned
on).
While fixing the debug message I noticed one additional
little bug (see patch description). The attached small
patch should fix both the debug msg and the bug.
Thanks,
Michal
9 years, 5 months
[PATCH] krb5: Check return value of sss_krb5_princ_realm
by Lukas Slebodnik
ehlo,
yet another warning from clang static analyser.
sss_krb5_princ_realm set output parameter realm to NULL and len to 0
in case of failure. Clang static analysers repoted warning
"Null pointer passed as an argument to a 'nonnull' parameter"
in function match_principal. It was possible, that realm_name with value NULL
could be used in strncmp.
Function sss_krb5_princ_realm is used on other places for printing(formatting)
realm_name and NULL can be safely used as a argument for printf-like
functions.
Patch is attached.
LS
9 years, 5 months
sssd.conf ownership
by Jakub Hrozek
Hi,
I was going through our design page that describes the rootless sssd and
I'd like to discuss the default ownership of sssd.conf a bit more.
In the design document we proposed to change the default ownership to
sssd.sssd. This wouldn't widen sssd.conf access as only root and the sssd
user could read the config. One reason for the change was the dbus helper
to change the config, which would otherwise run privileged.
But I wonder whether it's really the best approach. If we changed the
ownership to sssd.sssd, then we'd have to be careful about chowning the
file each time on startup because tools like authconfig or even customer's
puppet modules or whatnot will keep writing out the file as root.root. We
can't reasonably change all the external tools and chowning on each
startup seems a bit fragile (as opposed to chowning the databases which
is a one-time operation).
Also, if we kept the the config file owned by root, then making the
confdb read-only for worker processes would mean the worker processes
have no means of altering the config file even if they were taken over.
The downside of keeping the sssd.conf as root is that the augeas calls
would have to be moved to a setuid process -- and a new setuid process is
always a bit of a burden.
To sum up:
* sssd.sssd
(+) don't need any privileged code to access sssd.conf
(-) need to chown the file on each startup
* root.root
(+) config file is only writable by privileged processes
(+) we're able to make the confdb read-only
(-) need privileged code to perform sssd.conf changes
I do realize that the complexity of creating the setuid helpers is much
larger than the complexity of writing a function to chown a file, but
for some reason the chowning feels a bit fragile to me and my gut
feeling is that the config file would better be only accessible by
root...
What do the other developers think?
9 years, 5 months
[PATCH] TESTS: Add test for mmap cache client crash
by Lukas Slebodnik
ehlo,
I was not able to mock functions with linker flang -wrap when
they was called indirectly by another function from dynamic library.
(It works with dirrect invocation of function)
mc_client_tests_LDFLAGS = \
-Wl,-wrap,sss_nss_check_header \
-Wl,-wrap,sss_open_cloexec \
$(NULL)
This is a reason why I wrote mocked function in unit test
e.g.
__real_sss_open_cloexec
__wrap_sss_open_cloexec
sss_open_cloexec
If you know better way how to mock functions I will be glad to change test.
LS
9 years, 5 months
Should we fork sssd-1-12 from master already?
by Jakub Hrozek
Hi,
we are already receiving patches that refactor e.g cache lookups or some
of the functions in nested group processing.
I would prefer those to be only included in master for some time and
start stabilizing sssd-1-12 already.
Anyone against forking sssd-1-12 from master?
9 years, 5 months