Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 beta 4/12/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!hpda!fortune!amd!decwrl!decvax!genrad!wjh12!harvard!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: Bugs in the at command - summary
Message-ID: <2074@rlgvax.UUCP>
Date: Wed, 4-Jul-84 18:02:34 EDT
Article-I.D.: rlgvax.2074
Posted: Wed Jul  4 18:02:34 1984
Date-Received: Mon, 23-Jul-84 01:35:24 EDT
References: <1336@sri-arpa.UUCP> <487@rayssd.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 24

> The problem is that "at" uses the owner of the file to establish
> the uid & gid of the process... Similar things can happen if you allow
> users to "chown" ownership away.

This is a problem on "USG" UNIX (S3, S5, etc.).  Some versions of S3 and
S5 have added "at", and some didn't plug this hole (they probably have
since then - if they didn't, they should!).  The plug was suggested to
me by the same person who pointed out the hole, and is also used in the
S5R2 version of "at".

The setuid bit is sort of a passkey; a setuid program allows you some access
to the privileges of the user owns the program file.  Since "USG"
UNIX allows you to give files away, this requires that the setuid bit be
turned off when a file is given away (by other than the super-user), which
is done.  An "at" file owned by a given user also is similar; if it is
given away, it should not allow the "at" job to have the privileges of the
new user.  The solution is to put the setuid bit on all "at" job files,
and have the "at" daemon require the setuid bit to be on.  If the file is
given away, the setuid bit goes away, and the job is no longer valid.  Any
other software that uses the owner of a file to grant privileges can probably
use the same trick.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy