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

[Guillem Jover <guillem@debian.org>]

On Wed, 2020-08-05 at 00:58:27 +0200, Ansgar wrote:
> On Tue, 2020-08-04 at 23:50 +0200, Guillem Jover wrote:
> > 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.
> 
> The same reason that `rm -rf /` gives an error these days? :)

That might have been a good argument if root honored those missing
write-perms, but it does not. :)

> People modify files managed by dpkg from time to time and wonder why
> these modifications suddenly disappear on upgrades.  Or some package
> might assume a file is writable and use it, then data is lost on
> upgrade.  (I'm fairy certain to remember bug reports about that for
> files shipped in /var.)

Well, I guess they'll eventually understand what's going on?

> Various files are read-only anyway (such as `/bin/bash` when a shell is
> running).

But, that's just the standard Unix behavior of ETXTBSY, where the
file has been mmap()ed so you don't want to allow writing to it,
otherwise you'd end up modifying running code, ending up in at least
crashes. You can of course still unlink or rename these files though.

> > 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?
> 
> You can still do that if you really want to; editors will warn users if
> they modify read-only files, even when they provide an override to
> force writing the file.

Actually, editors need explicit support for this when running as root,
and this pretty much mostly applies to text files. For example nano
has no such protection.

So, I'm still failing to see what kind of protection this gives
anyway, because it does not really protect from root itself.

> > > 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.
> 
> Why would non-root users not be able to create files with 444
> permissions instead of 644?

First, due to the missing perms in directories. If we ignored that and
only removed write perms from regular files, then that would still
fail due to the needed delayed syncing required by new filesystem
so that they can behave in a sensible way when it comes to
performance. And while, f.ex., at least Linux does support passing a
read-only fd to fsync(2), this is a non-portable assumption.

Thanks,
Guillem