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

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

El 28/2/25 a las 17:17, cacin@allfreemail.net escribió:
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.

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.

El 28/2/25 a las 20:53, cacin@allfreemail.net escribió:

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.