Xref: utzoo comp.sys.att:3747 comp.unix.questions:8165 comp.unix.wizards:9836
Path: utzoo!utgpu!water!watmath!clyde!att!occrsh!rjd
From: rjd@occrsh.ATT.COM (Randy_Davis)
Newsgroups: comp.sys.att,comp.unix.questions,comp.unix.wizards
Subject: Re: Setuid on expreserve and exrecover
Summary: setuid on ex*preserve needed
Keywords: setuid, vi, expreserve, exrecover
Message-ID: <298@occrsh.ATT.COM>
Date: 14 Jul 88 20:17:42 GMT
References: <794@pttesac.UUCP>
Reply-To: rjd@occrsh.UUCP (Randy_Davis)
Organization: AT&T Network & Data Systems, OKC
Lines: 28

In article <794@pttesac.UUCP> robert@pttesac.UUCP (Robert Rodriguez) writes:
:Does anyone know the reason for /usr/lib/ex*preserve being
:set-user-id bin or root ?
:Ex*preserve is the program called by "vi" when a connection is
:dropped without having saved the contents of the vi buffer.
:Please e-mail me, and I'll summerize to the net if there is interest.

Email bounced, so:

Uh, yeah:  The setuid root or bin is so that the /usr/lib/expreserve
program can write the file in the directory /usr/preserve, which should be
owned by bin and mode 755, e.g.:

$ ls -ald /usr/expreserve
drwxr-xr-x   5 bin      bin           80 Mar 22 10:56 /usr/preserve

(Otherwise it would not be able to write to the directory....)

  In this way, only you (and root and bin) can remove any of your files
stored there, and only you can change them, as the files are normally
stored mode 600 or 700.
  "/usr/lib/exrecover" should be the same mode as expreserve so it can
retrieve them for you....

   To the person saying that its distributors should be shot: I do beleive that
the superuser bug has been fixed! (about eight years ago...)

Randy