vc-mode-line ancient, root-specific code for buffer-read-only

vc-mode-line ancient, root-specific code for buffer-read-only

[Glenn Morris]

Hi,

vc-mode-line contains this:

    ;; If the user is root, and the file is not owner-writable,
    ;; then pretend that we can't write it
    ;; even though we can (because root can write anything).
    ;; This way, even root cannot modify a file that isn't locked.
    (and (equal file buffer-file-name)
         (not buffer-read-only)
         (zerop (user-real-uid))
         (zerop (logand (file-modes buffer-file-name) 128))
         (setq buffer-read-only t)))

Some version of this has been present since at least 1996.

It is buggy in that it has a race condition: (file-modes buffer-file-name)
will return nil if the file has been deleted, and logand will error.

Eg this happens if you run make lisp/vc/vc-bzr-tests as root, which is
presumably what prompted Debian to disable one of the tests

https://sources.debian.org/patches/emacs/1:26.1+1-1/0010-Mark-vc-bzr-test-fauilt-bzr-autoloads-as-unstable-fo.patch/


I would like to suggest just removing that vc-mode-line code.
It's for locking VCS, is buggy, and doesn't even make sense.
root cannot "write anything", unless we are concerned with odd cases
like a file being writable by other but not owner. Ie locked files would
be marked read-only for root anyway.

Re: vc-mode-line ancient, root-specific code for buffer-read-only

[Paul Eggert]

Glenn Morris wrote:
> 
> I would like to suggest just removing that vc-mode-line code.
> It's for locking VCS, is buggy, and doesn't even make sense.
> root cannot "write anything", unless we are concerned with odd cases
> like a file being writable by other but not owner. Ie locked files would
> be marked read-only for root anyway.

The code is indeed for locking VCs which are almost entirely obsolete now. And 
the code has problems if the file has been deleted, as you noted. So I would 
favor removing the code as being more trouble than it's worth.

On the other hand I don't follow the comment "root cannot 'write anything'". 
Traditionally, root can write any file that is writable to any user (and even 
some files that no other users can write to), so in that sense roote can "write 
anything".

Re: vc-mode-line ancient, root-specific code for buffer-read-only

[Andreas Schwab]

On Dez 18 2018, Paul Eggert <eggert@cs.ucla.edu> wrote:

> On the other hand I don't follow the comment "root cannot 'write
> anything'". Traditionally, root can write any file that is writable to any
> user (and even some files that no other users can write to), so in that
> sense roote can "write anything".

A common exception is remote filesystems like NFS where the server is
using root_squash.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: vc-mode-line ancient, root-specific code for buffer-read-only

[Glenn Morris]

Paul Eggert wrote:

> On the other hand I don't follow the comment "root cannot 'write
> anything'". Traditionally, root can write any file that is writable to
> any user (and even some files that no other users can write to), so in
> that sense roote can "write anything".

This vc code is only relevant to files that are not writable by their owner.
The most normal example would be a file with mode 444.
If you visit such a file with Emacs as root, it is marked read-only anyway.
(That is what I meant by root not being able to "write anything";
obviously root can change the permissions and then do whatever.)

The vc-mode line code would only make a difference to files with odd
modes like 466. But RCS (for example) changes file modes to 444 when it
locks a file, so AFAICS the vc-mode code serves no purpose even for RCS.

Re: vc-mode-line ancient, root-specific code for buffer-read-only

[Stefan Monnier]

FWIW, I'm definitely in favor of removing that code.


        Stefan

Re: vc-mode-line ancient, root-specific code for buffer-read-only

[Paul Eggert]

Thanks for the explanation; the change still looks good to me.