I can't think of a reason to start gssproxy by default (i.e. WantedBy=multi-user.target) if nothing is using it. Switching to socket activation will mean less constant RSS on every Atomic Host system, but the main reason to do this is to work around VMs with low entropy: https://bugzilla.redhat.com/show_bug.cgi?id=1212082
The only problem with this is that each section in the gssproxy can specify a different socket (for cases where using the same socket would be ambiguos as 2 apps need to behave differently with thye same inputs). Other than that I think we should have a way to do socket actication in the simple cases, maybe we can even do some magic with generators at boot time to create the right socket listings from the configuration ?
GSSProxy will not be a heavy consumer of entropy since with newer krb5 it will be using getrandom() from the urandom pool.
The getrandom() usage in krb5 has been back-ported to F24 hasn't it? That's what I'm seeing in bug 1212082 comment 21. If I read getrandom(2) right, getrandom("YbP\250\1<\377\216I\212\6B9\212\223\227\3050\212i\240%\\\372\264\203woLD\307R", 32, 0) = 32 <70.908856> is using the urandom pool but that will block if the entropy pool has not yet been initialised.
(In reply to Oliver Henshaw from comment #3) > The getrandom() usage in krb5 has been back-ported to F24 hasn't it? That's > what I'm seeing in bug 1212082 comment 21. That's correct. > If I read getrandom(2) right, > getrandom("YbP\250\1<\377\216I\212\6B9\212\223\227\3050\212i\240%\\\372\264\2 > 03woLD\307R", 32, 0) = 32 <70.908856> > is using the urandom pool but that will block if the entropy pool has not > yet been initialised. Right, and the only time that'll be is when there's no good entropy on the system.
(In reply to Robbie Harwood from comment #4) > Right, and the only time that'll be is when there's no good entropy on the > system. Also known as "during the boot-up of a VM without the virtio-rng device"...
(In reply to Stephen Gallagher from comment #5) > (In reply to Robbie Harwood from comment #4) > > Right, and the only time that'll be is when there's no good entropy on the > > system. > > Also known as "during the boot-up of a VM without the virtio-rng device"... Right, and since this is a cryptographic tool, you wouldn't want it to be using the unitialized pool then anyway...
Sure, but the point of this ticket is that you probably don't want to be doing the initial secret generation on boot-up if you aren't actually using gssproxy. However, since it's installed and enabled by default, you don't get to make that choice. If it was socket-activated (or some other form of lazy instantiation), it would only start when something necessitated it and also later in the boot process when the system may have generated some usable entropy.
(In reply to Robbie Harwood from comment #6) > Right, and since this is a cryptographic tool, you wouldn't want it to be > using the unitialized pool then anyway... I don't want it to run at all unless it's being used. And again, while I would say the decision to use (~GRND_NONBLOCK) here makes sense from am upstream code perspective, it makes the people who are responsible for "editions/products/complete systems" look silly, since OpenSSH doesn't do that, and I feel confident in calling SSH the "default experience". Though, interestingly OpenSSH -> OpenSSL, which looks like it uses RDRAND directly from userspace if available. So presumably if one is doing host CPU passthrough on post-Ivy Bridge machines for virt, entropy isn't an issue for OpenSSH.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.