Bug#1115317: Draft Ballot Re: Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)
Hi, Following input on IRC, a revised draft, with an extra option "2", meaning the previous option "2" is now option "3". As previously, I'd appreciate "this ballot is OK" and/or suggested amendments. ===8<=== In #1115317, the Technical Committee (TC) was asked about the future of /var/lock, following a systemd upload which made this directory only writable by root. Bug #1110980 was opened against systemd, pointing out that FHS (and thus Debian Policy) has /var/lock as the standard interface for system-wide locks of serial devices and similar. In the upstream discussion of the issue ( https://github.com/systemd/systemd/issues/38563 ) the systemd authors declined to remain FHS-compliant, but rather noted that downstream distributions might wish to arrange for systemd to create /var/lock with appropriate permissions if they wish to. Nevertheless, #1110980 was closed "wontfix". The TC is sympathetic to the argument that flock(2) is a superior locking mechanism, and that an end-state where all existing software that still uses locks in /var/lock is migrated to using flock(2) instead would be desirable. 0) The Technical Committee notes that an important part of the role of a Debian Developer is ensuring that software in Debian complies with Debian Policy. That a particular upstream is not interested in FHS compliance is not a sufficient reason for a Debian package to disregard the FHS as it is incorporated into Debian Policy. The TC therefore resolves that systemd shall provide /var/lock with relaxed enough permissions that existing Debian software that uses /var/lock for system-wide locks of serial devices (and similar purposes) works again. The TC exercises its power under constitution #6.1.4 to overrule the systemd maintainers in this regard. 1) This change to systemd must persist until a satisfactory migration of impacted software has occurred and Policy updated accordingly. 2) This change to systemd must persist until Policy has been updated to allow it 3) This change to systemd must persist until the TC allows otherwise, which the TC expects to do once a suitable transition plan has been agreed. Ballot options: A) Issue items 0 + 1 B) Issue items 0 + 2 C) Issue items 0 + 3 N) Further discussion ===8<===
Bug#1115317: Draft Ballot Re: Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)
Hi, At the last TC meeting we discussed this bug; I think our conclusion then was that systemd needs to comply with policy and thus FHS regarding /var/lock which still needs to be usable for serial device locks, and we talked about a couple of options for how bounded our decision should be. I was asked to draft a ballot. Here's a draft - please LMK you're OK with it or propose amendments. I think the "The TC is sympathetic to..." paragraph represents consensus, but if you'd like it to be ballot-optional, LMK. ===8<=== In #1115317, the Technical Committee (TC) was asked about the future of /var/lock, following a systemd upload which made this directory only writable by root. Bug #1110980 was opened against systemd, pointing out that FHS (and thus Debian Policy) has /var/lock as the standard interface for system-wide locks of serial devices and similar. In the upstream discussion of the issue ( https://github.com/systemd/systemd/issues/38563 ) the systemd authors declined to remain FHS-compliant, but rather noted that downstream distributions might wish to arrange for systemd to create /var/lock with appropriate permissions if they wish to. Nevertheless, #1110980 was closed "wontfix". The TC is sympathetic to the argument that flock(2) is a superior locking mechanism, and that an end-state where all existing software that still uses locks in /var/lock is migrated to using flock(2) instead would be desirable. 0) The Technical Committee notes that an important part of the role of a Debian Developer is ensuring that software in Debian complies with Debian Policy. That a particular upstream is not interested in FHS compliance is not a sufficient reason for a Debian package to disregard the FHS as it is incorporated into Debian Policy. The TC therefore resolves that systemd shall provide /var/lock with relaxed enough permissions that existing Debian software that uses /var/lock for system-wide locks of serial devices (and similar purposes) works again. The TC exercises its power under constitution #6.1.4 to overrule the systemd maintainers in this regard. 1) This change to systemd must persist until a satisfactory migration of impacted software has occurred and Policy updated accordingly. 2) This change to systemd must persist until the TC allows otherwise, which the TC expects to do once a suitable transition plan has been agreed. Ballot options: A) Issue items 0 + 1 B) Issue items 0 + 2 N) Further discussion ===8<=== Thanks, Matthew
Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)
On Sep 24, Matthew Vernon wrote: It seems to me that Debian Policy requires FHS compliance in this regard; would you be amenable to reverting this change in systemd (to make it policy-compliant again) at least until we can come up with a transition plan, please? As I mentioned in #1110980, I think that /var/lock/ should be writeable by group dialout (at least until a different locking scheme will be agreed project-wide) but we should not make it world writeable again for all the good reasons explained by Luca and the other systemd upstream maintainers. (While this fixes cu it does not help uucico, but as a long time UUCP user I would be happy to work on moving the internal-use UUCP lock files if the maintainer needs help.) -- ciao, Marco signature.asc Description: PGP signature
Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)
Hello Systemd maintainers, The fallout from #1110980 has reached the technical committee, where the changes to /run/lock permissions is causing problems for software that uses it for lock files per FHS. I see from the upstream issue both that some of systemd upstream consider FHS obsolete; but they do also envisage that distributions that want to keep /run/lock FHS-compliant could choose to do so downstream of systemd. It seems to me that Debian Policy requires FHS compliance in this regard; would you be amenable to reverting this change in systemd (to make it policy-compliant again) at least until we can come up with a transition plan, please? I think in any case #1110980 should be reopened at severity serious until this is resolved - any objections? Thanks, Matthew
Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)
Thorsten Alteholz writes: > Due to a change in systemd, the directory /run/lock is no longer world > writable, but uucp uses this directory to create its lock files (as it is > documented in FHS). As you can see in #1110981 there already is a > complaint from a user that uucp no longer works. Let me add a tiny but significant detail to this discussion. While I haven't personally used all of uucp in quite some time (but am pleased to see it having a resurgence of interest in the ham radio world for store and forward messaging over HF digital radio links!), I use 'cu' almost constantly for interacting with embedded serial consoles on devices a USB connection away from my laptop. Having a change imposed by the systemd community cause 'cu' to break with no warning was really frustrating. My temporary "fix" was to manually open up the permissions on /run/lock, which is clearly not the right long term solution, so I look forward to your answer to Thorsten. Regards, Bdale signature.asc Description: PGP signature
Bug#1115317: advice for using /var/lock (which is a link to /run/lock) (#1110981)
Package: tech-ctte Severity: normal Hi, I am a bit stuck with #1110981 and need your advice on how to proceed. Due to a change in systemd, the directory /run/lock is no longer world writable, but uucp uses this directory to create its lock files (as it is documented in FHS). As you can see in #1110981 there already is a complaint from a user that uucp no longer works. The corresponding bug #1110980 in systemd was marked as "wontfix". So what do you recommend how to go on from here? Change Debian policy (as asked in #839), revert the change in systemd, find a Debian wide solution or let every package maintainer implement their own solution? Thorsten Relevant bugs up to now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110981 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110980 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839
