1. Forum
  2. Usenet
  3. LINUX.DEBIAN.POLICY

  • Bug#1099124: debian-policy: should 9.1.2 apply to /var/local too?

    From cacin@allfreemail.net@21:1/5 to All on Fri Feb 28 17:30:01 2025
    XPost: linux.debian.bugs.dist

    Package: debian-policy
    Severity: normal

    Dear policy team,

    I am seeking clarification regarding the applicability of Section 9.1.2
    of the Debian Policy [1] to the /var/local directory.

    The current policy states: "If /etc/staff-group-for-usr-local does not
    exist, /usr/local and all subdirectories created by packages should have permissions 0755 and be owned by root:root"

    This wording specifically addresses /usr/local and does not mention
    /var/local, which serves a related purpose. Currently, /var/local is
    owned by root:staff with 2775 permissions regardless of the existence of /etc/staff-group-for-usr-local.

    The base-files package creates /var/local with root:staff ownership and
    2775 permissions, despite the absence of /etc/staff-group-for-usr-local,
    as noted in #1039973 [2].

    Therefore, I would like to ask whether the policy should be revised to explicitly cover both /usr/local and /var/local, or if the omission of /var/local and its subdirectories from policy is intentional.

    [1] https://www.debian.org/doc/debian-policy/ch-opersys.html#site-specific-programs
    [2] https://bugs.debian.org/1039973

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Vila@21:1/5 to All on Fri Feb 28 21:50:01 2025
    XPost: linux.debian.bugs.dist

    El 28/2/25 a las 20:53, cacin@allfreemail.net escribió:
    To ensure consistency across all installations, it would make sense to
    align the ownership and permissions of /usr/local and /var/local.

    No, I'm not going to do that.

    I'll change the default for /var/local for trixie, but I want
    to preserve the freedom to change the default for /usr/local
    and for /var/local in an independent way.

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Vila@21:1/5 to All on Fri Feb 28 19:10:01 2025
    XPost: linux.debian.bugs.dist

    El 28/2/25 a las 17:17, cacin@allfreemail.net escribió:
    Therefore, I would like to ask whether the policy should be revised to explicitly cover both /usr/local and /var/local, or if the omission of /var/local and its subdirectories from policy is intentional.

    Hello. I was the one to word such section of Policy at the time,
    and it was never intended to be applied to /var/local.

    The file was called staff-group-for-usr-local, and that means
    staff group (ok, and mode 2775 too) for /usr/local, nothing else.

    So, I don't think repurposing the file for /var/local as well
    would be a good idea.

    The existence of a flag file for /usr/local was a requirement
    of the Technical Committee, who said "ok to change the default
    permissions, but only if you have a transition plan".

    Such a transition plan was justified for /usr/local, because there
    are other Debian packages creating subdirectories there, but IMO
    not for /var/local, which I believe we could switch in a single
    shot.

    The reason I have not done that yet is that I am not sure about
    the consequences.

    I've just made an experiment right now: modified base-files
    to ship /var/local as root:root and 755 (unconditionally), then installed it in a sid chroot.

    The permissions of /var/local did not change on the upgrade,
    which is probably the best possible outcome for this: Keep the old permissions if you upgraded from Debian 12 or earlier, but use
    755 and root:root for new installs of Debian 13.

    So here is a question for anybody familiar with dpkg
    handling of directory permissions: Can I rely on dpkg
    doing that? It's what I would like to happen.

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cacin@allfreemail.net@21:1/5 to All on Fri Feb 28 21:00:01 2025
    XPost: linux.debian.bugs.dist

    Source: debian-policy
    Followup-For: Bug #1099124

    It's reasonable to maintain the current ownership and permissions of the /var/local directory on existing debian installations and update the
    defaults for new installations. This approach may however result in a divergence between legacy and new installations, which would be an
    argument for not changing anything in the policy and keeping the
    directory as is. I would still consider the policy to be underdocumented regarding this point however.

    To ensure consistency across all installations, it would make sense to
    align the ownership and permissions of /usr/local and /var/local.
    Currently, these are only in sync by chance, if
    /etc/staff-group-for-usr-local exists.

    I'm not aware of anyone still using the staff group for the purposes of managing /usr/local and /var/local. I am however aware of security
    scanners that report the suid and sgid bits on executables and
    directories, and it's pointless for all debian installations (especially containers and virtual machines that are distributed to the whole world)
    to needlessly trigger those scanners on /var/local unconditionally. I'm
    not aware of any non-debian-based distributions that would still by
    default set the staff group and related permissions either.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to cacin@allfreemail.net on Fri Feb 28 17:40:01 2025
    XPost: linux.debian.bugs.dist

    On Fri, 28 Feb 2025 at 16:17:47 +0000, cacin@allfreemail.net wrote:
    The current policy states: "If /etc/staff-group-for-usr-local does not
    exist, /usr/local and all subdirectories created by packages should have >permissions 0755 and be owned by root:root"

    This wording specifically addresses /usr/local and does not mention >/var/local, which serves a related purpose.

    Specifically, the FHS describes /var/local as the place to put state for programs in /usr/local, similar to the relationship between /var and /usr.

    For completeness: the FHS also describes /etc/local (as a place to put
    the configuration of /usr/local programs), although base-files
    doesn't provide that, and as far as I know it isn't widely-adopted.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)