Created attachment 1850722 [details] Reproducer for the problem Hello, I think I have found a problem in the packaging of liblockfile, which makes it pretty useless. Basically I have compiled a mail user agent which uses liblockfile to lock my mailbox /var/spool/mail/USER, and liblockfile fails to do so. As indicated in /usr/share/doc/liblockfile/README: 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). If you are trying to lock a mailbox in a directory writable for group mail, the locking functions will call a helper application which runs setgid to do the actual locking. The helper application "dotlockfile" can also be used directly, for example for use in shellscripts. On my fedora35 system, my mailbox and its directory have these permissions: drwxrwxr-x. 1 root mail 14 10 dec. 11:38 /var/spool/mail -rw-rw----. 1 USER mail 42879 13 janv. 21:53 /var/spool/mail/USER Which basically means that, to be able to put a lockfile into this directory, one has to be root or be part of group mail. As my account is not part of this group, considering the README excerpt above, I expect that liblockfile spawns the setgid "dotlockfile" program to perform the lock. But it doesn't, and fails. Also the dotlockfile(1) manpage says: dotlockfile is installed with attribute SETGID mail and thus can also be used to lock and unlock mailboxes even if the mailspool directory is only writable by group mail. However, it is *not* setgid mail: -rwxr-xr-x. 1 root root 23856 22 juil. 17:06 dotlockfile Checking the source code (lockfile.c, Makefile.in, configure.in), I think what is missing is to #define MAILGROUP, which is normally done when --with-mailgroup is passed to "./configure" liblockfile.spec however does not pass this argument. I guess that is the root cause of the problem? To reproduce the problem: - Get some mail in your mailbox file inside /var/spool/mail/. You might want to use a command similar to: mail -s test $USER <<< test - Install the liblockfile-devel package - Compile and run the attached program that simply locks and unlocks the mail. The result on my system is: $ ./test Error creating tmp lockfile I however expect that it succeeds in locking (and unlocking) my mail. Thanks! Best regards Fabrice
Must be an ancient problem that doesn't affect Emacs and libetpan. As a side-note, there are several newer releases of liblockfile: https://github.com/miquels/liblockfile
Bug discovered in liblockfile 1.14 8.fc35.
Yes, of course, since 1.15 to 1.17 have not been packaged yet. What I meant is, you wrote """packaging of liblockfile ... pretty useless""", and since the packaging is unchanged for many years (it even needs some minor updates for older changes to the guidelines) and since liblockfile is not restricted to locking mailboxes in /var/spool/mail or running the external dotlockfile executable, it seems to me no symptoms have been noticed (and reported) before.
Hi Fabrice, thanks for the report and reproducer. I have rebased the package into the current version however unfortunately for now I couldn't resolve the problem you described. Even with mail group set on dotlockfile and/or with using --with-mailgroup I wasn't able to use dotlockfile or your test successfully without using sudo. I didn't find any relevant selinux logs either. I will try investigate further.
Good news: if I take the current source package (commit 1a50b71), and I add --with-mailgroup to the %configure line, it works! My reproducer succeeds! Could you please add the --with-mailgroup option? It defines the MAILGROUP macro, which changes the liblockfile code. Thanks!
Hmm, running this command in mock (local or koji): install -g mail -m 2755 dotlockfile /builddir/build/BUILDROOT/liblockfile-1.17-1.fc36.x86_64/usr/bin fails with: install: cannot change ownership of '/builddir/build/BUILDROOT/liblockfile-1.17-1.fc36.x86_64/usr/bin/dotlockfile': Operation not permitted How should we handle this case? (unfortunately I don't remember how I made things work on March 21st... manual action?)
No need to run install like that, since there is a proper %attr statement in the spec file's %files section to achieve the wanted thing. $ rpmlsv -p liblockfile-1.17-1.fc35.x86_64.rpm|grep dotl -rwxr-sr-x root mail 24376 /usr/bin/dotlockfile -rw-r--r-- root root 2167 /usr/share/man/man1/dotlockfile.1.gz
Yes, that is the problem. Installation with mailgroup is not permitted, but even with mailgroup set with %attr, required behavior is not achieved. I have also tried to change dotlockfile install part in Makefile, so installation wth mailgroup will pass, but it still didn't accomplish locking without sudo. I don't know how did you build it Fabrice, but I couldn't figure out way to package liblockfile into Fedora so it would behave as you expect.
In upstream Makefile.in, there are occurrences of "install -g GROUP". In the spec we have a sed that takes care of the "-g root" case. However, it misses the "-g $(MAILGROUP)" case. Specifying instead: sed -Ei "/install/ s/-g [^ ]+//" Makefile.in handles all cases. And by adding --with-mailgroup, liblockfile correctly uses the algorithm: - (1) try creating the lock in /var/spool/mail - it fails, so (2) it attempts to run the dotlockfile program to do it However, it fails to find dotlockfile: strace output: (1) openat(AT_FDCWD, "/var/spool/mail/.lk405223fedora", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = -1 EACCES (Permission denied) (2) newfstatat(AT_FDCWD, "/builddir/build/BUILDROOT/liblockfile-1.17-2.fc36.x86_64/usr/bin/dotlockfile", 0x7ffcc2440c60, 0) = -1 ENOENT (No such file or directory) As you can see in the attempted dotlockfile path, there is a mess between the DESTDIR and the --prefix. For the record: If I have an OS disk temporarily mounted in /mnt/disk, and I want to install my program into /usr/mylocal on that OS, Then I shall set DESTDIR=/mnt/disk and --prefix=/usr/mylocal liblockfile is messy in this regard, because is mixes the two, which makes it harder for packagers to do it right (thus the numerous --prefix, --bindir and so on in the %configure of the current .spec), and furthermore liblockfile does it wrong, where the path of the LOCKPROG (dotlockfile) contains DESTDIR, as we've seen above in the strace output. I've just submitted a tentative fix upstream: https://github.com/miquels/liblockfile/pull/15 I'd like to help the upstream maintainer. Let's see how it goes...
With my upstream pull request #15, and the following actions, it works: $ ./configure --enable-shared --with-mailgroup --prefix=/usr/mylocal $ make clean $ make $ sudo make install $ LD_LIBRARY_PATH=/usr/mylocal/lib /path/to/liblockfile-bug/test Success
I propose this change: https://src.fedoraproject.org/rpms/liblockfile/pull-request/1 It will apply the correct changes to the upstream Makefile.in (the ones from #15). I have installed the package on my laptop, and it locks my mail correctly.
Great, thanks for help and the PR Fabrice! I will push the changes into Fedora.
FEDORA-2022-5e0c6799d8 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-5e0c6799d8
FEDORA-2022-5e0c6799d8 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-7cda3a83a1 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7cda3a83a1
FEDORA-2022-670fc04629 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-670fc04629
FEDORA-2022-670fc04629 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-670fc04629` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-670fc04629 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-7cda3a83a1 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 --advisory=FEDORA-2022-7cda3a83a1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7cda3a83a1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-7cda3a83a1 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-670fc04629 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Michael Schwendt from comment #1) > Must be an ancient problem that doesn't affect Emacs and libetpan. It turns out that Fedora's build of Emacs doesn't actually use liblockfile, despite linking to it (see https://src.fedoraproject.org/rpms/emacs/pull-request/40).