Xref: utzoo comp.unix.questions:14671 comp.unix.wizards:17121
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!lzaz!hutch
From: hutch@lzaz.ATT.COM (R.HUTCHISON)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: at files and permissions
Message-ID: <669@lzaz.ATT.COM>
Date: 5 Jul 89 13:14:32 GMT
References: <1894@cbnewsh.ATT.COM>
Distribution: na
Organization: AT&T ISL Lincroft NJ USA
Lines: 53

From article <1894@cbnewsh.ATT.COM>, by bgt@cbnewsh.ATT.COM (barbara.tongue):
> Folks,
> 
> I have a question concerning at command.  Why does it
> neet the setuid bit?  Why does it need root permissions?
> That seems like a slight security hazard to me...
> 
> Please email in response.
> 
> Thanks!
> 
> -- 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> %%   The Speaking Tongue, AT&T   %%  C Code.  C Code Run.  Run, Code, RUN! %%
> %%    (..!att)!feathers!bgt      %%           PLEASE!!!!                   %%
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I believe that the setuid bit is set on the shell script itself so the
at command can tell if someone has been messing with it.  At least on
my system, the "at" shell scripts are owned by the person who executed
the "at" command.  When the "at" daemon is run, it assumes the
identity of the owner of the file and executed the commands found
therein.  If it finds that the ownership has changed, it won't execute
the script.  But, how does it do this?  read on...

Scenario:
If I wanted to be sneaky (and if "at" wasn't very smart), I could submit 
a "nasty" at job, go to the spool directory, and change the file's owner 
id to a target login and "at" would do the nasty to that login.  

file in /usr/spool/cron/atjobs after it was submitted through "at"

permissions: -r-Sr-Sr--		owner: hutch

after I change the ownership:

permissions: -r--r--r--		owner: target

The "at" daemon checks to see if the set user and group id bits are
still on.  If so, it assumes that all is OK and goes adead and
executs the script.  If it sees them off, it assumes that probably
someone has tried to change the ownership of the file and is doesn't
execute the script.

The "at" command actually doesn't use the permission bits for their
originally intended use (setuid), but rather because these bits are 
reset on a chown.

About "at" requiring "root" permission, I guess it needs it to write
into the "atjobs" directory.

Bob Hutchison
lzaz!hutch