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