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. 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
