andy@syma.sussex.ac.uk (Andy Clews) (03/27/90)
I work on a Sequent Symmetry S81 running DYNIX 3.0.15. My question could, however, apply to any UN*X box. I recently set up a command (atq) which lists, in a `friendly' format, the jobs waiting in /usr/spool/at (i.e. files produced by the "at" command). I would like to expand the command to enable users to cancel their own jobs - i.e. remove their own files in /usr/spool/at. Files in this directory are owned and writeable by the people who gave the corresponding "at" command, but because /usr/spool/at can only at present be written by root, users cannot delete their own "at" files. Can anyone suggest a way in which I can give this sort of access to /usr/spool/at without compromising system security by allowing the world to write to it? I'm a bit wary of creating a setuid'd program to do it. -- Andy Clews, Computing Service, Univ. of Sussex, Brighton BN1 9QN, England JANET: andy@syma.sussex.ac.uk BITNET: andy%syma.sussex.ac.uk@uk.ac
jimmy@pyrltd.UUCP (Jimmy Aitken) (03/28/90)
In article <2409@syma.sussex.ac.uk> andy@syma.sussex.ac.uk (Andy Clews) writes: >I work on a Sequent Symmetry S81 running DYNIX 3.0.15. My question >could, however, apply to any UN*X box. > >Files in this directory are owned and writeable by the people who gave >the corresponding "at" command, but because /usr/spool/at can only at >present be written by root, users cannot delete their own "at" files. > >Can anyone suggest a way in which I can give this sort of access to >/usr/spool/at without compromising system security by allowing the world >to write to it? I'm a bit wary of creating a setuid'd program to do it. The way that I 'delete' at jobs when I don't want them to run is by truncating the file. The easiest way to do this is to: echo > /usr/spool/at/<whatever> for csh and sh or > /usr/spool/at/<whatever> for sh Jimmy -- -m------- Jimmy Aitken ...!mcvax!ukc!pyrltd!jimmy ---mmm----- Pyramid Technology Ltd jimmy@pyra.co.uk -----mmmmm--- Pyramid House, Solartron Rd jimmy@pyramid.pyramid.com -------mmmmmmm- Hants GU14 7PL, ENGLAND (+44) 252 373035
jim@cs.strath.ac.uk (Jim Reid) (03/28/90)
In article <2409@syma.sussex.ac.uk> andy@syma.sussex.ac.uk (Andy Clews) writes: >I work on a Sequent Symmetry S81 running DYNIX 3.0.15. My question >could, however, apply to any UN*X box. Not so. Most System V boxes have a different at/cron system. The System V at command supports a -r option, enabling users to delete their at jobs. >Files in this directory are owned and writeable by the people who gave >the corresponding "at" command, but because /usr/spool/at can only at >present be written by root, users cannot delete their own "at" files. > >Can anyone suggest a way in which I can give this sort of access to >/usr/spool/at without compromising system security by allowing the world >to write to it? I'm a bit wary of creating a setuid'd program to do it. Well, there's no need for a setuid program at all. (Or setgid for that matter either.) Just have the user run a script to identify the appropriate shell script. All that's then needed is to delete the contents of the file. The at daemon will run the now empty file at the appointed time and then delete it. Since the user already owns the shell script, this does not require any special setuid/setgid permissions. Incidentally, the BSD at command doesn't need to be setuid anything. All it needs is to have write permission on the spool directory. Setgid to the unique group ownership of the spool directory will do fine. i.e.:- % ls -lsgd /usr/bin/at /usr/spool/at 24 ---x--s--x 1 bin at 24576 May 21 1988 /usr/bin/at 1 drwxrwxr-x 3 root at 512 Mar 28 08:00 /usr/spool/at Jim
stevedc@syma.sussex.ac.uk (Stephen D Carter) (03/29/90)
From article <2823@baird.cs.strath.ac.uk>, by jim@cs.strath.ac.uk (Jim Reid): > In article <2409@syma.sussex.ac.uk> andy@syma.sussex.ac.uk (Andy Clews) writes: > >> >>Can anyone suggest a way in which I can give this sort of access to >>/usr/spool/at without compromising system security by allowing the world >>to write to it? I'm a bit wary of creating a setuid'd program to do it. > > Well, there's no need for a setuid program at all. (Or setgid for that > matter either.) Just have the user run a script to identify the appropriate > shell script. All that's then needed is to delete the contents of the file. > The at daemon will run the now empty file at the appointed time and then > delete it. Since the user already owns the shell script, this does not > require any special setuid/setgid permissions. > I'm not happy with this reply. It is a workaround and not a resolution. In a real world the users should not have to effectivelt delete their file - after all they might want to run that job again. While folks like Andy, you and me who are clearly not naive users couls cope with this, think about how naive users in offices running applications systems will cope. They just want to at a job, then having realised they don't, they want to drop it, not delete it. Stephen Carter, Systems Manager, The Administration, The University of Sussex, Falmer, Brighton BN1 9RH, UK Tel: +44 273 678203 Fax: +44 273 678335 JANET: stevedc@uk.ac.sussex.syma EARN/BITNET : stevedc@syma.sussex.ac.uk UUCP: stevedc@syma.uucp ARPA/INTERNET: stevedc%syma.sussex.ac.uk@nsfnet-relay.ac.uk
guy@auspex.auspex.com (Guy Harris) (03/30/90)
>>I work on a Sequent Symmetry S81 running DYNIX 3.0.15. My question >>could, however, apply to any UN*X box. > >Not so. Most System V boxes have a different at/cron system. The System >V at command supports a -r option, enabling users to delete their at jobs. For that matter, 4.3BSD comes with "atq" and "atrm" commands, which let you list and remove jobs....