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 <ans...@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? :) 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.) Various files are read-only anyway (such as `/bin/bash` when a shell is running). > 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. > > 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. Probably mostly debhelper (dh_fixperms)? > > 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? Ansgar