Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site rayssd.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!mhuxl!ulysses!allegra!rayssd!ras
From: ras@rayssd.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Bugs in the at command - summary
Message-ID: <487@rayssd.UUCP>
Date: Tue, 3-Jul-84 13:28:53 EDT
Article-I.D.: rayssd.487
Posted: Tue Jul  3 13:28:53 1984
Date-Received: Wed, 4-Jul-84 03:40:51 EDT
References: <1336@sri-arpa.UUCP>
Organization: Raytheon Co., Portsmouth RI
Lines: 24

Sorry for not responding to the first request, but there is 
another bug that may be out there on some systems, depending
on how protections are set up.  These were found on V7 and 4.* BSD
systems, and the fix is easy enough.

The problem is that "at" uses the owner of the file to establish
the uid & gid of the process, and that if the spool/at directory is
writable, or (worse yet) the files themselves are writeable, an un-
authorized user could add stuff in, etc.
Similarly, if the directory is writeable, and the (ab)user finds a
willing and permissive file (owned by root, writable by all, and in
the same file system as spool/at), he or she can edit it and link it
into the spool/at directory.  Similar things can happen if you allow
users to "chown" ownership away.

One fix is to make the spool/at directory 711 mode and "at" setuid
during the creat and chown, and then do a setuid(getuid()). I imagine
there are others.


-- 

Ralph Shaw,	{allegra, decvax!brunix, linus, ccieng5}!rayssd!ras
Raytheon Co,	 Submarine Signal Division., Portsmouth, RI 02871