We are working with several kerberos-REALMS and are trying to get our clients to store their kerberos tickets in a DIRECTORY. This seems to work nicely for clients not authenticating at login, with the following configuration set in /etc/krb5.conf. ... [libdefaults] ...
default_ccache_name = DIR:/tmp/krb5cc_%{uid} ...
user@server:~$ klist Ticket cache: DIR::/tmp/krb5cc_888/tkt Default principal: user@REALM
Valid starting Expires Service principal 09/22/19 17:35:50 09/23/19 17:35:48 krbtgt/user@REALM
Each ticket is stored in a separate file.
For clients using sssd for login, I want to set up the same behavior. But when I attempt to login the system creates an "/tmp/krb5cc_${UiD}" - but here the directory don't get the excutable bit set (that is the directory get 0600-permission), and the login fails.
In the man-page from Debian-buster (sssd-version: 1.16.3), there are to settings that seems to regulate this behaviour :
krb5_ccachedir (string) Directory to store credential caches. All the substitution sequences of krb5_ccname_template can be used here, too, except %d and %P. The directory is created as private and owned by the user, with permissions set to 0700.
Default: /tmp
krb5_ccname_template (string) Location of the user's credential cache. Three credential cache types are currently supported: "FILE", "DIR" and "KEYRING:persistent". The cache can be specified either as TYPE:RESIDUAL, or as an absolute path, which implies the "FILE" type. In the template, the following sequences are substituted:
[...]
If the template ends with 'XXXXXX' mkstemp(3) is used to create a unique filename in a safe way.
When using KEYRING types, the only supported mechanism is "KEYRING:persistent:%U", which uses the Linux kernel keyring to store credentials on a per-UID basis. This is also the recommended choice, as it is the most secure and predictable method.
The default value for the credential cache name is sourced from the profile stored in the system wide krb5.conf configuration file in the [libdefaults] section. The option name is default_ccache_name. See krb5.conf(5)'s PARAMETER EXPANSION paragraph for additional information on the expansion format defined by krb5.conf.
NOTE: Please be aware that libkrb5 ccache expansion template from krb5.conf(5) uses different expansion sequences than SSSD.
Default: (from libkrb5)
...
I have tried to both set and unset, the two parameters in question like this:
krb5_ccachedir = /tmp/krb5cc_%U
krb5_ccname_template = DIR: %d krb5_ccname_template = DIR:%d/krb5cc_%U_XXXXXX
But the configuration-options seems to be ignored, no matter what I do, and I have the same behavior: A non-executable directory is created and the user is unable to login.
If I set the +x bit on the directory manually as the root-user, everything works.
On Sun, Sep 22, 2019 at 04:16:58PM -0000, Jostein Fossheim wrote:
We are working with several kerberos-REALMS and are trying to get our clients to store their kerberos tickets in a DIRECTORY. This seems to work nicely for clients not authenticating at login, with the following configuration set in /etc/krb5.conf. ... [libdefaults] ...
default_ccache_name = DIR:/tmp/krb5cc_%{uid} ...
user@server:~$ klist Ticket cache: DIR::/tmp/krb5cc_888/tkt Default principal: user@REALM
Valid starting Expires Service principal 09/22/19 17:35:50 09/23/19 17:35:48 krbtgt/user@REALM
Each ticket is stored in a separate file.
For clients using sssd for login, I want to set up the same behavior. But when I attempt to login the system creates an "/tmp/krb5cc_${UiD}" - but here the directory don't get the excutable bit set (that is the directory get 0600-permission), and the login fails.
In the man-page from Debian-buster (sssd-version: 1.16.3), there are to settings that seems to regulate this behaviour :
krb5_ccachedir (string) Directory to store credential caches. All the substitution sequences of krb5_ccname_template can be used here, too, except %d and %P. The directory is created as private and owned by the user, with permissions set to 0700.
Default: /tmp
krb5_ccname_template (string) Location of the user's credential cache. Three credential cache types are currently supported: "FILE", "DIR" and "KEYRING:persistent". The cache can be specified either as TYPE:RESIDUAL, or as an absolute path, which implies the "FILE" type. In the template, the following sequences are substituted:
[...]
If the template ends with 'XXXXXX' mkstemp(3) is used to create a unique filename in a safe way.
When using KEYRING types, the only supported mechanism is "KEYRING:persistent:%U", which uses the Linux kernel keyring to store credentials on a per-UID basis. This is also the recommended choice, as it is the most secure and predictable method.
The default value for the credential cache name is sourced from the profile stored in the system wide krb5.conf configuration file in the [libdefaults] section. The option name is default_ccache_name. See krb5.conf(5)'s PARAMETER EXPANSION paragraph for additional information on the expansion format defined by krb5.conf.
NOTE: Please be aware that libkrb5 ccache expansion template from krb5.conf(5) uses different expansion sequences than SSSD.
Default: (from libkrb5)
...
I have tried to both set and unset, the two parameters in question like this:
krb5_ccachedir = /tmp/krb5cc_%U
krb5_ccname_template = DIR: %d krb5_ccname_template = DIR:%d/krb5cc_%U_XXXXXX
But the configuration-options seems to be ignored, no matter what I do, and I have the same behavior: A non-executable directory is created and the user is unable to login.
If I set the +x bit on the directory manually as the root-user, everything works.
First, the DIR cache is not the most tested, to the best of my knowledge no distribution uses it as the default. RHEL-6 uses FILE, RHEL-7 KEYRING and RHEL-8 KCM. Looking at the code, the directories should be created with 0700. I wonder if the permissions are OK if you use /run/user/%uid/ccache or something similar instead?
Is there a reason to not use KEYRING?
I'm sorry for reviving this old thread, but I have the very same issue.
Debian Buster does not have KEYRING:PERSISTENT support enabled in the kernel:
cat /boot/config-4.19.0-13-amd64 | grep PERSISTENT_KEY # CONFIG_PERSISTENT_KEYRINGS is not set
I wonder if the directory creation problem is a consequence of the UID mask of the sssd_be process, i.e. similar to: https://github.com/SSSD/sssd/commit/14050f35224360883e20ebd810d3eb40f39267cf
On Sun, Dec 13, 2020 at 05:26:52PM -0000, Oliver Freyermuth wrote:
I'm sorry for reviving this old thread, but I have the very same issue.
Debian Buster does not have KEYRING:PERSISTENT support enabled in the kernel:
cat /boot/config-4.19.0-13-amd64 | grep PERSISTENT_KEY # CONFIG_PERSISTENT_KEYRINGS is not set
I wonder if the directory creation problem is a consequence of the UID mask of the sssd_be process, i.e. similar to: https://github.com/SSSD/sssd/commit/14050f35224360883e20ebd810d3eb40f39267cf
Hi,
can you check if the following patch works for you?
diff --git a/src/providers/krb5/krb5_child.c b/src/providers/krb5/krb5_child.c index cab7b27..058e84b 100644 --- a/src/providers/krb5/krb5_child.c +++ b/src/providers/krb5/krb5_child.c @@ -972,8 +972,13 @@ static krb5_error_code create_ccache(char *ccname, krb5_creds *creds) bool switch_to_cc = false; #endif
- /* Set a restrictive umask, just in case we end up creating any file */ - umask(SSS_DFL_UMASK); + /* Set a restrictive umask, just in case we end up creating any file or a + * directory */ + if (strncmp(ccname, "DIR:", 4) == 0) { + umask(SSS_DFL_X_UMASK); + } else { + umask(SSS_DFL_UMASK); + }
/* we create a new context here as the main process one may have been * opened as root and contain possibly references (even open handles?)
Please open a ticket at https://github.com/SSSD/sssd/issues/new for this issue.
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Am 15.12.20 um 10:14 schrieb Sumit Bose:
On Sun, Dec 13, 2020 at 05:26:52PM -0000, Oliver Freyermuth wrote:
I'm sorry for reviving this old thread, but I have the very same issue.
Debian Buster does not have KEYRING:PERSISTENT support enabled in the kernel:
cat /boot/config-4.19.0-13-amd64 | grep PERSISTENT_KEY # CONFIG_PERSISTENT_KEYRINGS is not set
I wonder if the directory creation problem is a consequence of the UID mask of the sssd_be process, i.e. similar to: https://github.com/SSSD/sssd/commit/14050f35224360883e20ebd810d3eb40f39267cf
Hi,
can you check if the following patch works for you?
diff --git a/src/providers/krb5/krb5_child.c b/src/providers/krb5/krb5_child.c index cab7b27..058e84b 100644 --- a/src/providers/krb5/krb5_child.c +++ b/src/providers/krb5/krb5_child.c @@ -972,8 +972,13 @@ static krb5_error_code create_ccache(char *ccname, krb5_creds *creds) bool switch_to_cc = false; #endif
- /* Set a restrictive umask, just in case we end up creating any file */
- umask(SSS_DFL_UMASK);
/* Set a restrictive umask, just in case we end up creating any file or a
* directory */
if (strncmp(ccname, "DIR:", 4) == 0) {
umask(SSS_DFL_X_UMASK);
} else {
umask(SSS_DFL_UMASK);
}
/* we create a new context here as the main process one may have been
- opened as root and contain possibly references (even open handles?)
Hi,
thanks, that was fast! Indeed, it does, I confirmed that by patching sssd 1.16.3 on Debian Buster locally, and purging all "bad" directories, now they are created with correct mode :-)
Please open a ticket at https://github.com/SSSD/sssd/issues/new for this issue.
Done, here it is: https://github.com/SSSD/sssd/issues/5436
Many thanks for the quick help, Oliver
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Tue, Dec 15, 2020 at 01:49:00PM +0100, Oliver Freyermuth wrote:
Am 15.12.20 um 10:14 schrieb Sumit Bose:
On Sun, Dec 13, 2020 at 05:26:52PM -0000, Oliver Freyermuth wrote:
I'm sorry for reviving this old thread, but I have the very same issue.
Debian Buster does not have KEYRING:PERSISTENT support enabled in the kernel:
cat /boot/config-4.19.0-13-amd64 | grep PERSISTENT_KEY # CONFIG_PERSISTENT_KEYRINGS is not set
I wonder if the directory creation problem is a consequence of the UID mask of the sssd_be process, i.e. similar to: https://github.com/SSSD/sssd/commit/14050f35224360883e20ebd810d3eb40f39267cf
Hi,
can you check if the following patch works for you?
diff --git a/src/providers/krb5/krb5_child.c b/src/providers/krb5/krb5_child.c index cab7b27..058e84b 100644 --- a/src/providers/krb5/krb5_child.c +++ b/src/providers/krb5/krb5_child.c @@ -972,8 +972,13 @@ static krb5_error_code create_ccache(char *ccname, krb5_creds *creds) bool switch_to_cc = false; #endif
- /* Set a restrictive umask, just in case we end up creating any file */
- umask(SSS_DFL_UMASK);
- /* Set a restrictive umask, just in case we end up creating any file or a
* directory */
- if (strncmp(ccname, "DIR:", 4) == 0) {
umask(SSS_DFL_X_UMASK);
- } else {
umask(SSS_DFL_UMASK);
- } /* we create a new context here as the main process one may have been
- opened as root and contain possibly references (even open handles?)
Hi,
thanks, that was fast! Indeed, it does, I confirmed that by patching sssd 1.16.3 on Debian Buster locally, and purging all "bad" directories, now they are created with correct mode :-)
Hi,
great, thanks for the feedback.
Please open a ticket at https://github.com/SSSD/sssd/issues/new for this issue.
Done, here it is: https://github.com/SSSD/sssd/issues/5436
Thanks.
bye, Sumit
Many thanks for the quick help, Oliver
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org