On Sat, Jan 25, 2025 at 11:06:43AM +0200, Alexander Bokovoy wrote: > On Суб, 25 сту 2025, Zbigniew Jędrzejewski-Szmek wrote: > >On Fri, Jan 24, 2025 at 01:25:18PM -0300, Rafael Jeffman wrote: > >>Some of these packages might have the same issue as > >>softhsm/opendnssec as they use the same user, but, > >>currently user GECOS is different on both packages, > >>causing systemd-sysuers to fail (or warn). > > > >This is a preexisting bug in softhsm and opendnssec. In fact, it might > >be a ecurity issue, since two services will run under the same user. > >I'm not familiar with those packages, but in general there are two > >options: > >- if the user shall be shared, let on of the packages define the user > > and have the other package add Requires:user(…). > >- if the user shall not be shared, use a different user name in one > > or both packages. > > OpenDNSSEC and SoftHSM are coupled. SoftHSM's primary function is to be > used as the certificate store for OpenDNSSEC, this is why its default > data store is defined to be used by 'ods' user. Sorry if I'm missing something obvious, but shouldn't they use a different user but a common group? Rich. > We do rely in FreeIPA on OpenDNSSEC and this arrangement with SoftHSM, > so we do not expect this to be changed. > > OpenDNSSEC upstream wants to have a separate future for SoftHSM. > However, it is not entirely clear what that future will be, as there are > multiple options: from abandoning the code completely to living a > separate life in a different github organization. > > >The mechanism to create the users doesn't materially change the > >situation. If anything, the warning we'll now get from sysusers, if > >both packages are installed at the same time, is good, because it > >makes the problem easier to see. > > > >>IMHO, an approach similar to SPDX change should be made. > > > >A similar approach is being made: as mentioned in my original mail, > >I plan to open pull requests against packages. > > > >Zbyszek > >-- > >_______________________________________________ > >devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > >To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > >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.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > >Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > > -- > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
