GNOME Bugzilla – Bug 319246
logic bug in camel-lock-helper
Last modified: 2021-05-19 11:04:09 UTC
camel-lock-helper doe snot wotk as expected under some circumstances. In a nutshell, locking of Local Delivery accounts fails, if dot locking is built in but the directory conatining the mbox does not belong to the user, nor the owner of the binary. Details: 1) Evo built and installed by a user. Configure reports Dot Locking is available, File Locking is fcntl. The binarie are owned by the building user, especially $prefix/libexec/camel-lock-helper-1.2 which is important here. Fetching new mails or Local Delivery accounts fails: Error while Fetching Mail. Could not lock '/var/spool/mail/$USER' 2) Workarounds are: a) chmown root.root and chmod u+s for camel-lock-helper-1.2 b) Configure e-d-s with --disable-dot-locking Workaround a) works, as root got permissions on the dir and Dot Locking is permitted. b) works, as Dot Locking is omitted and File Locking works even as user. The logic bug in camel-lock-helper is clear: If Dot Locking fails, e-d-s does not check any other locking method. File Locking would work, as proofed above. However, e-d-s does not even try File Locking. To fix this, e-d-s should try different available locking methods, if the first one fails. Reproducible: Always
Setting Target Milestone. This logic bug should be ixed ASAP. IMHO this even should go in into Evo 2.4.2 / e-d-s 1.4.2.
Forgot to mention: It was Joseph Sacco who found out the details and raised the topic to me. :)
The GARNOME team works as a "team". -Joseph
Thanks dudes. But there are a few points which i would like to state: 1. Normal users would always install Evo as root. And this issue does *not* appear in such a case. 2. People who build (read *us* developers) install in local home directories would *always* know that we need to indeed have permissions set on /var/spool/mail/$user directory. Thoughts?? Rest assured, this shall be given a high priority
You are correct, that "normal users" would install by packages, thus as root. However, the logic bug still stands. The code just does not fall back to another locking method that actually does work, in case the first method fails. Obviously, it does not even try other methods than File Locking in this case. IMHO this is a bug in the code and should be fixed. Item 2 is not correct, though. Messing with the directory permissions of /var/spool/mail/ is not a sane option in a multiuser environment. Regarding "us": There are projects out there that enable the user to install GNOME (and thus Evolution) as user. GARNOME installs to the users home by default even. At least in such (admittedly non-average) scenarios this bug bites the user / developer. To sum it up: e-d-s knows about more than one locking method. The code should be smart enough to actually use more than one method, if need be. The current code isn't smart at all. Thanks for giving this a high priority. :)
changed Target Milestone to 1.4.2
Partha, have not heard from you on this yet ? still targeting this for 1.4.2 ?
1.4.2 is out already, re-targetting for 1.4.3
Any news on this? Raising priority. This should be fixed for 1.4.3. Anyway, since we're getting closer to the next stable release and it has been broken like this for a long time, 1.6.0 likely may be sufficient.
See bug 322727 for a related issue. The locking mechanism simply is broken and needs to be fixed ASAP.
changing target milestone from obsolete 1.4.3 to 1.6.x.
"asap" means 1.8 nowadays, sigh...
Well, it was never a major issue really, i mean on very few system dot locking does not work and they can ship with support for file locking. dont remember how hard it is to fix though, not trivial is what i remember.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/ Thank you for your understanding and your help.