Description of problem: currently, s390Utils needs liblockfile-devel for building ap-check . on the other hand, recently, liblockfile package has introduced setting a special gId to /usr/bin/dotlockfile for purpose of mailgroup which breaks setgid tests for Fedora - rawhide in s390x. So, we need to split out liblockfile-devel. Version-Release number of selected component (if applicable): Fedora - rawhide How reproducible: Run setgid tests from the fedora kola suite wihtout considering the gID set to /usr/bin/dotlockfile and see it fail.
If a test is failing, then the test needs to be updated. There is nothing to do on the s390utils side if we don't want to disable the functionality provided by liblockfile in ap-check. Which we don't, I believe. You might ask the liblockfile maintainers to put the binary into a separate subpackage, but in such small package it makes no sense.
Dear liblockfile team, is it possible to move the binary to a separate subpackage and have the library part of liblockfile in a package by itself ? in FCOS, we donot use the binary but rather the rest of the library. Thank you.
I feel like it's important to add more context to this request.. Dan (s390utils) and Richard (liblockfile) bear with us for a moment. We (the Fedora CoreOS and Red Hat CoreOS teams) are trying to identify and qualify any new setuid or setgid binaries that come into Fedora CoreOS and Red Hat CoreOS. We have a test that notifies when any new/unexpected setuid or setgid binaries show up. After the recent s390utils build, which pulls in liblockfile, we started a discussion [1] in our upstream tracker that eventually lead to this request. We've done some analysis [2] and determined that s390utils doesn't use `dotlockfile` and it may even be served better by using a different (more generic, and not specific to mail applications) locking library so that it no longer requires liblockfile. This request is to inform liblockfile of the potential non-mail application of liblockfile and to try to discuss with both parties (s390utils and liblockfile) potential solutions. Thanks for any input you can provide here! [1] https://github.com/coreos/fedora-coreos-tracker/issues/1253 [2] https://github.com/coreos/fedora-coreos-tracker/issues/1253#issuecomment-1202989926
I wonder if lockfile-progs wouldn't be a better place for the dotlockfile utility. Or perhaps it's even redundant ...
Joe, this might be relevant from the enterprise point of view as well.
It is the purpose of liblockfile that the library execs the /usr/bin/dotlockfile binary to deal with the setgid mail case, rather than the app needing to be setgid itself. So it doesn't make sense moving the executable into a subpackage AFAICT.
Right, this https://github.com/coreos/fedora-coreos-tracker/issues/1253#issuecomment-1202989926 is spot on, thanks Dusty. If you just need a lockfile in /run just use open/O_EXCL, it seems way overkill to pull in liblockfile for that case.
The use case is more complex, it involves udev rules and mediated devices (mdevctl) and a pass-thru for crypto devices into guests ... But if there would exist some other solution I believe upstream would not be opposed ...
Hi guys. Problem with separating dotlockfile, as Joe stated, is that library uses the dotlockfile binary for some of its functionality. For that I think that it is undesirable to try separate them. Because of this and a fact that in a relatively recent past we had a bug related to a functionality of dotlockfile I think we can't say that the binary is redundant. Also the way gID is set for dotlockfile is implemented purposefully, therefore changing that is not a good option.
Thanks Richard. I'll switch the component back to s390utils for now so we can further discuss the use of this library in s390utils in this BZ.
My assumption is that the library is used to avoid race conditions in the udev rules for the vfio-ap feature. So it would be risky to build s390utils without liblockfile. I would recommend opening an upstream issue to discuss the use of liblockfile and possible alternatives.
Suggestion to split the liblockfile package while keeping compatibility: - Add a sub-package with only the setgid binary - Have the library recommend the sub-package - Have applications that truly need the setgid functionality explicitly depend on the sub-package This enables applications to depend only on the library if they don't need the functionality provided by the setgid binary. This also solves the issue for us as we don't enable recommends by default.
Having library behaviour contingent on a weak dep like that is not a good idea, there is no way to guarantee the "real" dependency is in place from the API caller.
I think that it is not as much question of other packages dependencies to liblockfile as the fact that people would expect fully functional library. General Upstream info about liblockfile says this: This library implements a number of functions found in -lmail on SysV systems. These functions are designed to lock the standard mailboxes in /var/mail (or wherever the system puts them). In additions, this library adds a number of functions to create, manage and remove generic lockfiles. So it is more like locking/unlocking of mails is primary function which could be expected out of the box instead as additional functionality obtained by subpackage. Dotlockfile is essential part of this functionality as can be also seen in Makefile: liblockfile.so: solockfile.o $(CC) $(LDFLAGS) -fPIC -shared -Wl,-soname,liblockfile.so.1 \ -o liblockfile.so solockfile.o -lc solockfile.o: lockfile.c $(CC) $(CFLAGS) -DLIB -DLOCKPROG=\"$(bindir)/dotlockfile\" \ -c lockfile.c -o solockfile.o With this said, I'm not very inclined to this solution.
(In reply to Richard Lescak from comment #14) > I think that it is not as much question of other packages dependencies to > liblockfile as the fact that people would expect fully functional library. > General Upstream info about liblockfile says this: > > This library implements a number of functions found in -lmail on SysV > systems. These functions are designed to lock the standard mailboxes in > /var/mail (or wherever the system puts them). > > In additions, this library adds a number of functions to create, > manage and remove generic lockfiles. > I think what we've identified is that this "additional functionality" is useful on its own (i.e. it could actually be a new dependency that gets pulled in by liblockfile itself and other non-mail focused apps could use it), but we should probably look for other solutions to that problem. Thank you Richard for having this discussion with us.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
Hi all. I did the quick initial analysis in https://github.com/coreos/fedora-coreos-tracker/issues/1253#issuecomment-1202989926 and I was observing the progress of the discussion in this ticket. At this point, I think it would be useful to move this discussion upstream to see whether the s390-tools developers would be ok with dropping the liblockfile dependency and implement that logic internally instead. I tried to quickly assemble something compatible with the current logic, and a non-intrusive patch seems overall feasible. I'll now try to summarize this discussion into a github ticket, and post my current code there too.
The upstream ticket is at https://github.com/ibm-s390-linux/s390-tools/issues/142. For reference, my current patch attempt is at https://github.com/lucab/s390-tools/pull/1.
Upstream fixed this in https://github.com/ibm-s390-linux/s390-tools/commit/25a70ac5a81ec0b3fa74715e30cc3675d2f018d8. The fix got released in https://github.com/ibm-s390-linux/s390-tools/releases/tag/v2.24.0. Once packaged in Fedora, that should allow dropping the liblockfile dependency in Fedora.
Thanks Luca for taking on that work.
s390utils 2.24.0 has been built for rawhide, F-37 and F-36 builds will follow next week
FEDORA-2022-5a9600e505 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-5a9600e505
FEDORA-2022-5a9600e505 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-5a9600e505` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5a9600e505 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-6c49fb07f9 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-6c49fb07f9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6c49fb07f9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-6c49fb07f9 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-5a9600e505 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.