[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable



On Tue, 2020-08-04 at 13:56:45 -0700, Russ Allbery wrote:
> Ansgar <ansgar@debian.org> writes:
> > 10.9 Permissions and owners currently says
> 
> > | Files should be owned by root:root, and made writable only by the
> > | owner and universally readable (and executable, if appropriate),
> > | that is mode 644 or 755."
> 
> > However most files shouldn't be modified as modifications will just be
> > lost (e.g. everything installed by the package manager that isn't
> > handled as a conffile).  It also gives more permissions than the minimum
> > needed.

I'm not sure why we need to protect the local sysadmin(s) from this? Also
root can just write to any file regardless of the permissions. Countless
times I've modified local files, for example, to fix an issue that is
pending upload. And while that does not require write perms if done as
root, both of the above would seem to counter this as a good reason
for this change?

(I could also see this being performed by one of the other "admin" roles
in the system that is not root.)

> > I think static files should not be writable instead, so every file under
> > /usr (and /bin, /sbin, /lib*; or everything dpkg installs that is not a
> > conffile) should have 444 (or 555).
> 
> I assume this is in support of systems, containers, or jails where UID 0
> may not have CAP_FOWNER?

If that's the reason, it certainly was not clear from the original
report. :)

> The basic argument makes sense to me, but this is the sort of change where
> we'll need to figure out a transition strategy coordinated across multiple
> packages, since this behavior is encoded in a lot of places.  Maybe it
> would make sense for Guillem to weigh in first and indicate whether this
> would be a problem on the dpkg side and if he sees any concerns.  Copying
> debian-dpkg@lists for that.

Thanks! Was meaning to comment anyway. :)

This would break installations as non-root, as those users will not
have enough privs to create the objects to extract. So that alone seems
like a non-starter.

Thanks,
Guillem


Reply to: