Bug#617315: policy /usr/local edge case failure
Joey Hess <joeyh@debian.org> writes:
> Policy requires that creation/removal of directories in /usr/local
> never fail, but its example does fail as seen in this bug report.
> Apparently the problem is that the chown or chmod could fail.
> One approach would be to guard them like this:
> if [ ! -e "$dir" ]; then
> if mkdir "$dir" 2>/dev/null; then
> if chown "$user":"$group" "$dir"; then
> chmod "$mode" "$dir" || true
> fi
> fi
> fi
> If the chown fails, the directory is left with the wrong user:group,
> but it is either root:root, or some other trusted group, like staff, to
> which /usr/local is setgid, so that seems ok. Any member of that group
> could mkdir /usr/local/foo themselves and get a similar directory.
> I'm unsure whether the chmod should only be run once the chown succeeds,
> or always be run. If the chmod is widening the permissions (4775), it
> seems best to only do that if the directory has the right owner. If it's
> narrowing the permissions (0700), it might be better to always do it.
> I'm also unsure whether the error messages should be suppressed.
Well, the real answer to this bug is that the Technical Committee decided
quite some time back that we should not be using special permissions for
/usr/local any longer, but this is currently stalled waiting for someone
to find the time to do the archive-wide work required to come up with a
transition plan. (See #538392.)
This seems like an edge case, and one that isn't really aligned with our
long-term direction, so I'm inclined to not worry too much about the
corner-case details and just go with what you have above. This is a weird
enough case that I don't think the error messages need to be suppressed;
it's probably a good idea to have a quiet mention somewhere that something
strange happened. Given the unusual circumstances, I don't know that it
matters a great deal whether the chmod runs if the chown fails, but since
we're currently trying to set directories to a fairly permissive mode, I
think it's best to do what you do above.
To me, this is all a non-normative change, since it's in an example, so
I'm going to go ahead and commit the modified version that you describe
above. The next release of Policy won't be for a little bit, so people
will still have time to raise issues in response to this if they see any
and we can then discuss it again.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: