Fedora Account System
Red Hat Associate
Red Hat Customer
For some time, krb5 configuration has been put in /var/lib/sss/pubconf/krb5.include.d. Presumably the intent is to avoid modifying /etc/krb5.conf directly, which I support. However, we have for some time been providing /etc/krb5.conf.d for these files - so there's no need to add your own directory. Please stop using /var/lib/sss/pubconf/krb5.include.d/ entirely in favor of /etc/krb5.conf.
*in favor of /etc/krb5.conf.d
Is this about IPA using SSSD's include directory or is the thing you actually dislike SSSD putting the files into /var in the first place?
(In reply to Jakub Hrozek from comment #2) > Is this about IPA using SSSD's include directory or is the thing you > actually dislike SSSD putting the files into /var in the first place? I don't want a second directory now that we have krb5.conf.d. In general, my goal is for /etc/krb5.conf to stop being modified by programs entirely. I'm given to understand that the reason these files are /var is that sometimes they need to be modified at runtime due to trust changes; in that case, symlinking them into krb5.conf.d from elsewhere (e.g., from somewhere in /var) would be fine.
(In reply to Robbie Harwood from comment #3) > (In reply to Jakub Hrozek from comment #2) > > Is this about IPA using SSSD's include directory or is the thing you > > actually dislike SSSD putting the files into /var in the first place? > > I don't want a second directory now that we have krb5.conf.d. I can see that having a single directory is cleaner, but is there some other reason behind this? > In general, > my goal is for /etc/krb5.conf to stop being modified by programs entirely. > Yes, this makes total sense to me. > I'm given to understand that the reason these files are /var is that > sometimes they need to be modified at runtime due to trust changes; in that > case, symlinking them into krb5.conf.d from elsewhere (e.g., from somewhere > in /var) would be fine. I haven't tested this, but does the libkrb5 include functionality support recursively stepping into subdirectories? e.g. would it be enough to create a 'sssd' subdirectory as a symlink to the /var/lib/sss/pubconf/krb5.include.d ? The reason for this is that sssd can also run as an unprivileged user and the /etc/krb5.conf.d/ directory is (of course) only writable by root.
(In reply to Jakub Hrozek from comment #4) > (In reply to Robbie Harwood from comment #3) > > (In reply to Jakub Hrozek from comment #2) > > > Is this about IPA using SSSD's include directory or is the thing you > > > actually dislike SSSD putting the files into /var in the first place? > > > > I don't want a second directory now that we have krb5.conf.d. > > I can see that having a single directory is cleaner, but is there some other > reason behind this? Well, you have to modify krb5.conf to set it up. I don't ship the /var/ path - you're modifying it to get that. That's most of it, but there's also the weirdness of requiring admins to look for config files in two place, which is pretty minor by comparison. > > I'm given to understand that the reason these files are /var is that > > sometimes they need to be modified at runtime due to trust changes; in that > > case, symlinking them into krb5.conf.d from elsewhere (e.g., from somewhere > > in /var) would be fine. > > I haven't tested this, but does the libkrb5 include functionality support > recursively stepping into subdirectories? e.g. would it be enough to create > a 'sssd' subdirectory as a symlink to the > /var/lib/sss/pubconf/krb5.include.d ? No, we don't recur. > The reason for this is that sssd can also run as an unprivileged user and > the /etc/krb5.conf.d/ directory is (of course) only writable by root. Well sure, but you had to run as root at the time you were writing to krb5.conf, so you can just make the symlinks at that point, yes?
(In reply to Robbie Harwood from comment #5) > (In reply to Jakub Hrozek from comment #4) > > (In reply to Robbie Harwood from comment #3) > > > (In reply to Jakub Hrozek from comment #2) > > > > Is this about IPA using SSSD's include directory or is the thing you > > > > actually dislike SSSD putting the files into /var in the first place? > > > > > > I don't want a second directory now that we have krb5.conf.d. > > > > I can see that having a single directory is cleaner, but is there some other > > reason behind this? > > Well, you have to modify krb5.conf to set it up. Fair point. I agree the system config files should be mostly immutable. (I'm not sure if the include dir should be under /etc/ but that's another debate..) > I don't ship the /var/ > path - you're modifying it to get that. That's most of it, but there's also > the weirdness of requiring admins to look for config files in two place, > which is pretty minor by comparison. > > > > I'm given to understand that the reason these files are /var is that > > > sometimes they need to be modified at runtime due to trust changes; in that > > > case, symlinking them into krb5.conf.d from elsewhere (e.g., from somewhere > > > in /var) would be fine. > > > > I haven't tested this, but does the libkrb5 include functionality support > > recursively stepping into subdirectories? e.g. would it be enough to create > > a 'sssd' subdirectory as a symlink to the > > /var/lib/sss/pubconf/krb5.include.d ? > > No, we don't recur. > > > The reason for this is that sssd can also run as an unprivileged user and > > the /etc/krb5.conf.d/ directory is (of course) only writable by root. > > Well sure, but you had to run as root at the time you were writing to > krb5.conf, so you can just make the symlinks at that point, yes? No, sssd doesn't modify krb5.conf[*], it just relies on whoever set sssd up (typically ipa-client-install, realmd) to include the sssd pubconf directory into the krb5.conf. And the installers typically run as root. But this is not a total blocker, we could use oddjob or some setuid helper or the installer adding ACLs to the sssd user or whatnot. I'm just saying it's not as trivial as s/pubconf/krb5.include.d/ [*] SSSD only "touches" krb5.conf when it writes new data into the include dir to make sure a subsequent krb5 invocation picks up the new stuff So if you agree, I would create an SSSD counterpart of this bug which would be blocking the IPA changes.
(In reply to Jakub Hrozek from comment #6) > (In reply to Robbie Harwood from comment #5) > > (In reply to Jakub Hrozek from comment #4) > > > (In reply to Robbie Harwood from comment #3) > > > The reason for this is that sssd can also run as an unprivileged user and > > > the /etc/krb5.conf.d/ directory is (of course) only writable by root. > > > > Well sure, but you had to run as root at the time you were writing to > > krb5.conf, so you can just make the symlinks at that point, yes? > > No, sssd doesn't modify krb5.conf[*], it just relies on whoever set sssd up > (typically ipa-client-install, realmd) to include the sssd pubconf directory > into the krb5.conf. And the installers typically run as root. > > But this is not a total blocker, we could use oddjob or some setuid helper > or the installer adding ACLs to the sssd user or whatnot. I'm just saying > it's not as trivial as s/pubconf/krb5.include.d/ > > So if you agree, I would create an SSSD counterpart of this bug which would > be blocking the IPA changes. Is sssd creating new files? If sssd only updates and never creates, then there wouldn't need to be any special logic - just modify the existing files. (Otherwise, yes, go ahead.) > [*] SSSD only "touches" krb5.conf when it writes new data into the include > dir to make sure a subsequent krb5 invocation picks up the new stuff I don't understand what you're saying here.
(In reply to Robbie Harwood from comment #7) > > So if you agree, I would create an SSSD counterpart of this bug which would > > be blocking the IPA changes. > > Is sssd creating new files? If sssd only updates and never creates, then > there wouldn't need to be any special logic - just modify the existing > files. (Otherwise, yes, go ahead.) > Currently SSSD writes new files. After your comment, I actually wondered if SSSD could just modify a file that would be initially empty, but I guess that might be racy with multiple sssd domains, so creating new files is actually probably safer. > > [*] SSSD only "touches" krb5.conf when it writes new data into the include > > dir to make sure a subsequent krb5 invocation picks up the new stuff > > I don't understand what you're saying here. Sorry about that :) what I tried to say is that the only non-read operation on /etc/krb5.conf itself is modifying its mtime, similar to what the touch(1) utility does.
(In reply to Jakub Hrozek from comment #8) > (In reply to Robbie Harwood from comment #7) > > > [*] SSSD only "touches" krb5.conf when it writes new data into the include > > > dir to make sure a subsequent krb5 invocation picks up the new stuff > > > > I don't understand what you're saying here. > > Sorry about that :) what I tried to say is that the only non-read operation > on /etc/krb5.conf itself is modifying its mtime, similar to what the > touch(1) utility does. Can you tell me more? Why do you do this? krb5 has some support for config reloading in running processes, but we never documented it as a feature and didn't think it was being relied upon.
It is the only way to cause other processes to realod the whole config. The only things libkrb5 looks at to decide if krb5.conf has been changed and the profile needs reloading is the main krb5.conf file.
(In reply to Robbie Harwood from comment #9) > (In reply to Jakub Hrozek from comment #8) > > (In reply to Robbie Harwood from comment #7) > > > > [*] SSSD only "touches" krb5.conf when it writes new data into the include > > > > dir to make sure a subsequent krb5 invocation picks up the new stuff > > > > > > I don't understand what you're saying here. > > > > Sorry about that :) what I tried to say is that the only non-read operation > > on /etc/krb5.conf itself is modifying its mtime, similar to what the > > touch(1) utility does. > > Can you tell me more? Why do you do this? krb5 has some support for config > reloading in running processes, but we never documented it as a feature and > didn't think it was being relied upon. Code-wise there's nothing much to tell: https://github.com/SSSD/sssd/blob/master/src/util/domain_info_utils.c#L256 The function is called whenever sssd updates any file under its pubconf directory. As far as git history tells me, this is to force long-running processes to re-read the domain-realm mappings etc.
(In reply to Simo Sorce from comment #10) > It is the only way to cause other processes to realod the whole config. > The only things libkrb5 looks at to decide if krb5.conf has been changed and > the profile needs reloading is the main krb5.conf file. Please file a bug, thanks.
This is know and have been discussed with Tom and Greg in the past, I bet there is a bug already, but IIRC there was no good way to solve it.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Upstream ticket: https://pagure.io/freeipa/issue/7445
The IPA team decided that the current behavior suits its needs well.