Bug 1225792

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

I am absolutely in favor of this.  One thing that I will be doing soon (if only based on the number of open bugs it would resolve) is to add a default include directory to the krb5.conf we ship.  An autogenerated file could be dropped there, which should take care of any issues I think.

(In reply to Robbie Harwood from comment #4)
> I am absolutely in favor of this.  One thing that I will be doing soon (if
> only based on the number of open bugs it would resolve) is to add a default
> include directory to the krb5.conf we ship.  An autogenerated file could be
> dropped there, which should take care of any issues I think.

That would be ideal. Which fedora version do you think that could be included in? In any case let me know when that feature is on.

krb5-1.13.2-7.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15661

krb5-1.13.2-6.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15660

Rawhide - right now.  fc23 and fc22 - when there's enough karma on the bodhi.  fc21 - probably never; the version of krb5 there wasn't even rebased to 1.13.

Apologies for the delay, I had to make it build again (some RPM verification has changed since we last touched the version in Fedora, it seems).

krb5-1.13.2-7.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update krb5'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15661

krb5-1.13.2-6.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update krb5'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15660

Hi,
 I'm thinking how this could with crypto-policies dropping a file in the krb5.d directory. The issues that I see are:
1. Who owns the file?
2. What happens if libkrb5 is not installed? Should the directory belong to crypto-policies?

We could solve it by giving that directory to some OS component. What do you think?

For 1, I would think that crypto-policies would own the file.

For 2, I think the directory belonging to crypto-policies in that case is fine; I believe RPM is okay with this.  Going forward, my understanding is that it will become increasingly difficult to have a system installation without libkrb5, and so at some point it would no longer be a problem.

(In reply to Robbie Harwood from comment #12)
> For 1, I would think that crypto-policies would own the file.
> For 2, I think the directory belonging to crypto-policies in that case is
> fine; I believe RPM is okay with this.  Going forward, my understanding is

So if I understand your suggestion is for crypto-policies package to own '/etc/krb5.conf.d/' and for the kerberos packages to depend on crypto policies?

While that work and solve this particular problem, it would be problematic to handle when a 3rd package would need to drop a file there. It would have to depend on crypto-policies which is quite weird. 


> that it will become increasingly difficult to have a system installation
> without libkrb5, and so at some point it would no longer be a problem.

There are certainly systems without libkrb5 and crypto-policies should be able to work without it. Docker systems for example don't pull all the desktop or server dependencies.

(In reply to Nikos Mavrogiannopoulos from comment #13)
> (In reply to Robbie Harwood from comment #12)
> > For 1, I would think that crypto-policies would own the file.
> > For 2, I think the directory belonging to crypto-policies in that case is
> > fine; I believe RPM is okay with this.  Going forward, my understanding is
> 
> So if I understand your suggestion is for crypto-policies package to own
> '/etc/krb5.conf.d/' and for the kerberos packages to depend on crypto
> policies?
> 
> While that work and solve this particular problem, it would be problematic
> to handle when a 3rd package would need to drop a file there. It would have
> to depend on crypto-policies which is quite weird. 

I believe it is permitted for multiple RPMs to create this directory?

Yes, it seems that is the case [0]. There is an example with gtk-doc and evolution. So that would be the solution. Let's put F24 (rawhide) as target, and make crypto-policies install the config file in the shared directory, and libkrb5 (or whoever owns the directory) to depend on crypto-policies. Does it sound reasonable?

[0]. https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership

I'm confused, sorry.  Why does libkrb5 need to depend on crypto-policies?

My reading of your link is that this case falls under the bash-completion vs. git+bzr case.  Multiple applications will be placing files here, not just crypto-policies, and crypto-policies will not be depending on libkrb5.

What do you think?

krb5-1.13.2-7.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

If we go on the path of libkrb5 using the policies that are set by crypto-policies it has to Require that package. Otherwise there can be scenarios under which libkrb5 doesn't follow the policy.

Isn't that the desired case if crypto-policies is not installed, though?  Or is crypto-policies going to be a package present on all Fedora systems?

(In reply to Robbie Harwood from comment #19)
> Isn't that the desired case if crypto-policies is not installed, though? 

I am not sure I follow you. The goal is to have the crypto policies applied when libkrb5 is present. That is why libkrb5 should Require the crypto policies. Does that make sense?

It is the same approach we used in gnutls, openssl, and the other packages that adhere to policy. We either have packages that follow the policy or not. We will not have packages that may or may not follow the policy depending on crypto-policies presence. If we go that way it would be a nightmare to figure the state of the system.

I've updated policies to generate a file with the "permitted_enctypes". You can view the available options for LEGACY, DEFAULT and FUTURE policies at:
https://github.com/nmav/fedora-crypto-policies/tree/master/profiles

What I forgot to ask is whether the user will be able to override them (e.g., by modifying the krb5.conf directly?). If that's possible and you have no objections, then I think that is complete, and I'll commit it to rawhide.

Okay, I did some digging and it's not possible to have a fedora system without crypto-policies (trying to `dnf erase` them would remove protected packages dnf and systemd).  Apologies for the misunderstanding; the picture was the wrong way in my head.  I think I see what you're saying now.

Regarding overriding: yes, override is possible.  Based on the other bug reports requesting includedir support, I've actually included two locations in krb5.conf: one of them is the /etc/krb5.conf.d/ (to be owned by crypto-polocies) mentioned above, and the other is /usr/share/krb5.conf.d/ which is the preferred location for user snippets and will be owned by krb5.

Starting with fc24 - and fc24 only - I've dropped ownership of /etc/krb5.conf.d and started depending on crypto-policies instead.  (I believe this is what you asked for - please correct me if that's not right.)

krb5-1.13.2-7.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16547

I'm reopening as the feature is not yet complete. Let's close when both libkrb5 and crypto-policies provide that feature. I'll take care of it.

I would appreciate if you revert the [1] or include /etc/krb5.conf.d in the crypto-policies package, which is not the case at the moment:

# rpm -q crypto-policies
crypto-policies-20150518-2.gitffe885e.fc23.noarch

# rpm -ql crypto-policies
/etc/crypto-policies
/etc/crypto-policies/config
/usr/bin/update-crypto-policies
/usr/share/crypto-policies
/usr/share/crypto-policies/profiles
/usr/share/crypto-policies/profiles/DEFAULT-F21.settings
/usr/share/crypto-policies/profiles/DEFAULT-F22.settings
/usr/share/crypto-policies/profiles/DEFAULT.settings
/usr/share/crypto-policies/profiles/EMPTY.settings
/usr/share/crypto-policies/profiles/FUTURE-F21.settings
/usr/share/crypto-policies/profiles/FUTURE-F22.settings
/usr/share/crypto-policies/profiles/FUTURE.settings
/usr/share/crypto-policies/profiles/LEGACY-F21.settings
/usr/share/crypto-policies/profiles/LEGACY-F22.settings
/usr/share/crypto-policies/profiles/LEGACY.settings
/usr/share/licenses/crypto-policies
/usr/share/licenses/crypto-policies/COPYING.LESSER
/usr/share/man/man8/update-crypto-policies.8.gz

since this effectively breaks my system:

# LANG=en_US systemctl status gssproxy.service 
* gssproxy.service - GSSAPI Proxy Daemon
   Loaded: loaded (/usr/lib/systemd/system/gssproxy.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2015-09-24 21:22:30 CEST; 38min ago
  Process: 3544 ExecStart=/usr/sbin/gssproxy -D (code=exited, status=1/FAILURE)

Sep 24 21:22:30 localhost systemd[1]: Starting GSSAPI Proxy Daemon...
Sep 24 21:22:30 localhost gssproxy[3544]: Error reading configuration -1429577696: Unknown error -1429577696
Sep 24 21:22:30 localhost systemd[1]: gssproxy.service: Control process exited, code=exited status=1
Sep 24 21:22:30 localhost systemd[1]: Failed to start GSSAPI Proxy Daemon.
Sep 24 21:22:30 localhost systemd[1]: gssproxy.service: Unit entered failed state.
Sep 24 21:22:30 localhost systemd[1]: gssproxy.service: Failed with result 'exit-code'.

Going to downgrade to krb5-1.13.2-8.fc24 which hopefully resolves the issue for the moment.


[1] http://pkgs.fedoraproject.org/cgit/krb5.git/commit/?id=65ce267be1061e6349bb5f566b7abef0c48d7492

Is the problem the "%dir /etc/krb5.conf.d"? I think that based on the previous discussion it can be present in both crypto-policies and libkrb5. So instead of reverting the whole change which is correct, adding this should solve the issue.

The thing is that gssproxy does not create the directory anymore while crypto-policies does not create the directory yet. I am just user and I don't care in this case who owns what as long as my system works, which is not the case for krb5-1.13.2-8.fc24+.

(In reply to Vít Ondruch from comment #27)
> gssproxy does not create the directory

I meant krb5 of course.

What is the timeframe for crypto-policies owning this directory in Fedora?

krb5-1.13.2-7.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update krb5'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16547

So my reading of earlier comments suggested that crypto-policies should own krb5.conf.d and that libkrb5 should not.

Vit, I apologize for the delay in fixing your issue here; I know that it's a problem, but I need to make krb5 build from source in rawhide again before I can revert the change.

(In reply to Robbie Harwood from comment #31)
> Vit, I apologize for the delay in fixing your issue here; I know that it's a
> problem, but I need to make krb5 build from source in rawhide again before I
> can revert the change.

NP, I saw the build failure and I am happy with the older version so far.

Vit, the version in rawhide should fix the problem.  Thanks for being patient!

krb5-1.13.2-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

(In reply to Robbie Harwood from comment #33)
> Vit, the version in rawhide should fix the problem.  Thanks for being
> patient!

I can confirm that the recent update:

$ rpm -q krb5-libs 
krb5-libs-1.13.2-12.fc24.x86_64

works just fine. Thank you.

It should be so in rawhide as of version krb5-1.14-beta1-3.

Nikos,
Could you explain why krb5.conf from crypto-policies cannot be stored in /etc/krb5_conf.d/ ?

I read the packaging guidelines[1] and I cannot see any violation.
It says:
"
In this context, a package's "natural dependency chain" is defined as the set of packages necessary for that package to function normally. To be specific, you do not need to require a package for the sole fact that it happens to own a directory that your package places files in
"

So crypto-policies needn't require krb5-libs to store file in /etc/krb5.conf.d/
i would say it's similar case as with logrotate:
[root@55e16868112e /]# rpm -qf /etc/logrotate.d/
logrotate-3.9.1-2.fc23.x86_64

[root@55e16868112e /]# rpm -qf /etc/logrotate.d/*
chrony-2.2-1.fc24.x86_64
corosync-2.3.5-1.fc23.x86_64
cups-2.1.0-1.fc24.x86_64
dnf-conf-1.1.3-1.fc24.noarch
iscsi-initiator-utils-iscsiuio-6.2.0.873-29.git4c9d6f9.fc24.x86_64
krb5-server-1.14-3.fc24.x86_64
krb5-server-1.14-3.fc24.x86_64
numad-0.5-20.20150602git.fc23.x86_64
psacct-6.6.2-3.fc23.x86_64
rpmorphan-1.15-1.fc24.noarch
sssd-common-1.13.1-2.fc24.x86_64
rsyslog-8.12.0-2.fc24.x86_64
wpa_supplicant-2.4-5.fc24.x86_64
yum-3.4.3-508.fc24.noarch[root@55e16868112e /]# rpm -qf /etc/logrotate.d/
logrotate-3.9.1-2.fc23.x86_64
[root@55e16868112e /]# rpm -qf /etc/logrotate.d/*
chrony-2.2-1.fc24.x86_64
corosync-2.3.5-1.fc23.x86_64
cups-2.1.0-1.fc24.x86_64
dnf-conf-1.1.3-1.fc24.noarch
iscsi-initiator-utils-iscsiuio-6.2.0.873-29.git4c9d6f9.fc24.x86_64
krb5-server-1.14-3.fc24.x86_64
krb5-server-1.14-3.fc24.x86_64
numad-0.5-20.20150602git.fc23.x86_64
psacct-6.6.2-3.fc23.x86_64
rpmorphan-1.15-1.fc24.noarch
sssd-common-1.13.1-2.fc24.x86_64
rsyslog-8.12.0-2.fc24.x86_64
wpa_supplicant-2.4-5.fc24.x86_64
yum-3.4.3-508.fc24.noarch

https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership


BTW: there is also packaging bug in crypto-policies because the file /etc/crypto-policies/back-ends/krb5.config should be at least marked as ghost if it is generated and not part of rpm. I might file a separate bug If we agree that drop in file from crypto policies should be stored in /etc/krb5.conf.d/

The reason it is not stored there is to allow an administrator to disable crypto policies for kerberos (by removing the link file). This should be documented somewhere in kerberos doc (or at least in the spec file).

About the %ghost directive please open a new bug on crypto policies.