Re: RCS File (,v); it uses move-over operation

[Nutchanon Wetchasit]

On Mon, 19 Dec 2022 02:51:28 +0000
Philip Cupryk <phil.cupryk@istarchipusa.com> wrote:

> It does not need to be writable.
> It seems that the RCS command co (with lock)
> can override file permissions.

It briefly puzzled me at first too; but no, there's apparently no
setuid magic involved. RCS can do this as long as it has read access
to the archive file (*,v) in question, as well as write access
to the *directory* containing it.

This is because RCS does not modify the archive file by opening it
in write mode and modify it; RCS rather read the archive file
in, apply changes, and write a new archive file out under different name,
then move that over the old one; similar to how sophisticated
text editors save its files.

It does this to make sure that the file's entire revision history
won't go down the drain if something (like power outage,
machine freeze, `kill -9`, etc.) interrupted the check-in
or check-out process.

You can see this happening by creating test RCS archive
in a directory (except `/tmp` [1]) which is both writable by you
as well as an other user [2], check in a dummy revision,
look at the archive file's permission, then have that other user
check out with locking; and then look at the file permission again:

You would see that the archive file would suddenly change owner
as a result of operations I described above...

# mkdir ~/rcstest
# chmod o+w ~/rcstest
# ls -l -d ~/rcstest
drwxr-xrwx 2 root root 4096 Dec 22 04:28 /root/rcstest
# cd ~/rcstest
# echo "This is a test text file." > test.txt
# ci test.txt
test.txt,v  <--  test.txt
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> .
initial revision: 1.1
done
# ls -l
total 4
-r--r--r-- 1 root root 203 Dec 22 04:29 test.txt,v
# su nobody
$ co -l test.txt
test.txt,v  -->  test.txt
revision 1.1 (locked)
done
$ ls -l
total 8
-rw-r--r-- 1 nobody nogroup  26 Dec 22 04:29 test.txt
-r--r--r-- 1 nobody nogroup 215 Dec 22 04:29 test.txt,v
$ 

Note that RCS would still stop you [3] if it saw somebody
(who was not you) already having a lock on the same revision;
or when there was an access list in the archive
and your user name wasn't on it [4].

Hope this answers to your curiousity on how it works.

Cheers,
Nutchanon Wetchasit
(A fellow GNU RCS user)


P.S. The above terminal transcript is from a system running
     Debian GNU/Linux 7.0 "Wheezy" i386,
     with GNU RCS 5.8.1.


[1] Or any other directory with sticky bit (`chmod +t`) set
    in its permission for that matter; as it prevents
    a move-over operation from a different user,
    and fail any RCS operation that change the archive file.

[2] I figure the usual scenario back in RCS' heyday was people
    logging in to a shared institutional Unix machine;
    and they would be assigned Unix group ID(s) which corresponds
    to each project they were working on; and each project directory
    would then be gated by group-based permission (a la `chmod g+rwx`).

[3] RCS does have a specific command to break the lock set by others or
    even yourself (`rcs -u`) however. In some systems,
    breaking others' lock would send a naughty-kid alert up north,
    and you would get prank items instead of proper presents
    on the upcoming Christmas day. [5]

[4] See `man rcs` on `-a` and `-e` options. (Alternatively
    via GNU Textinfo `info rcs rcs`, or online at
    <https://www.gnu.org/software/rcs/manual/html_node/rcs.html#legacy>)
    Note that if there is already an access list in the archive file,
    RCS would allow only users listed on it to use these options.

[5] I'm kidding about the Santa [6]; this locking feature is more about
    avoiding accidential reversion of other team members' ninja-checkin
    than anything. But I suppose when RCS was configured with
    `--with-mailer` build-time option (it wasn't on my setup),
    it would send `mail` containing the details of your "naughty act"
    to the user who held the lock you have broken,
    so that he could apply 3-way `merge` before checking in
    the change he was working on.

[6] A reference to XKCD #838 "Incident" <https://xkcd.com/838/>.