robert@pttesac.UUCP (Robert Rodriguez) (07/14/88)
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. Thanks.
jmc@ptsfa.PacBell.COM (Jerry Carlin) (07/14/88)
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 ? Needed on BSD but not on System V due to chown() requiring root privileges. Do us all a favor and if you are a V. system chmod 555 ex*preserve and chmod 777 /usr/preserve. ex*preserve has a well-known security problem. If any vendor is still delivering systems with ex*preserve setuid they should be shot at sunrise. -- Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc To dream the impossible dream. To fight the unbeatable foe.
rjd@occrsh.ATT.COM (Randy_Davis) (07/15/88)
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...)
Randybrian@bradley.UUCP (07/18/88)
> /* Written 10:08 am Jul 14, 1988 by jmc@ptsfa.PacBell.COM */ > 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 ? > > Needed on BSD but not on System V due to chown() requiring root privileges. > > Do us all a favor and if you are a V. system chmod 555 ex*preserve and > chmod 777 /usr/preserve. ex*preserve has a well-known security problem. > If any vendor is still delivering systems with ex*preserve setuid they > should be shot at sunrise. I looked at /usr/lib/expreserve on one of the AT&T 3B15's here, and it is setuid root. Perhaps AT&T should be shot at sunrise? :-) ............................................................................... When the going gets weird, the weird turn pro. Brian Michael Wendt UUCP: {cepu,ihnp4,uiucdcs,noao}!bradley!brian Bradley University ARPA: cepu!bradley!brian@seas.ucla.edu (309) 677-2230 ICBM: 40 40' N 89 34' W
maart@cs.vu.nl (Maarten Litmaath) (07/19/88)
In article <298@occrsh.ATT.COM> rjd@occrsh.UUCP (Randy_Davis) writes: \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 ? \... \ To the person saying that its distributors should be shot: I do beleive that \the superuser bug has been fixed! (about eight years ago...) The OLD bug has been fixed. Generally the NEW bug has NOT been fixed... (recently discussed in comp.sys5.bugs) -- I'd rather live in Russia |Maarten Litmaath @ Free U Amsterdam: than in South-Africa... |maart@cs.vu.nl, mcvax!botter!ark!maart
jon@jonlab.UUCP (Jon H. LaBadie) (07/23/88)
In article <10800022@bradley>, brian@bradley.UUCP writes: > > Do us all a favor and if you are a V. system chmod 555 ex*preserve and > chmod 777 /usr/preserve. ex*preserve has a well-known security problem. > If any vendor is still delivering systems with ex*preserve setuid they > should be shot at sunrise. > I prefer the following scheme, it has the advantage of retaining a degree of privacy to users preserved editor buffers. 1. Create a new, separate group, e.g. "editor" 2. Chgrp on /usr/preserve to editor 3. Chmod on /usr/preserve to 774 4. Chgrp on /usr/lib/ex*preserve and /usr/lib/ex*recover to editor 5. Chmod on /usr/lib/ex*preserve and /usr/lib/ex*recover to 2751 i.e. set the group id bit Now the preserve/mechanism is functional without any root permissions, and the preserve directory is also protected. -- Jon LaBadie {att, ulysses, princeton}!jonlab!jon