belkin@teecs.UUCP (Hershel Belkin) (06/29/90)
Can anyone tell me if there is any way to scedule a process using "at" or crontab but have it run under a group ID that is different than one's login group ID? (Of course, I'm assuming that the user is a valid member of the group!) I've looked, but have not been able to come up with a solution (other than have a separate login entry for the user under a different group.. but that isn't a viable solution) The problem is that newgrp replaces your shell, so that your execution script no longer runs, and it has no provision (or none that I've seen) for passing the name of a script to run when it starts up. I even tried doing a newgrp with the "-" option and then using .profile to kick on the script, but that results in a lot of loud complaining (via mail) since the login is not from an interactive device! Is this such an unusual thing to want to do? Am I missing something obvious? Our users are often involved in numerous projects, which we control via the group ID mechanism. Often they would like to scedule some jobs to run a less-busy times, like overnight. But the jobs may relate to various projects, and require specific group ID settings in order to access certain directories, programs, etc. Another possible solution is writing a small C program (with setgid bit set) to start up the script, but these users can't set the setgid bit, so that means a lot of work for me! (And besides, it seems like a poor security decision to have such programs lying around). Any help out there? Has someone already solved this one? (Even a manual reference would be welcomed :-) Thanks -- +-----------------------------------------------+-------------------------+ | Hershel Belkin hp9000/825(HP-UX)| UUCP: teecs!belkin | | Test Equipment Engineering Computing Services | Phone: 416 246-2647 | | Litton Systems Canada Limited (Toronto) | FAX: 416 246-5233 | +-----------------------------------------------+-------------------------+
leo@ehviea.ine.philips.nl (Leo de Wit) (06/30/90)
In article <960005@teecs.UUCP> belkin@teecs.UUCP (Hershel Belkin) writes: |Can anyone tell me if there is any way to scedule a process using |"at" or crontab but have it run under a group ID that is different |than one's login group ID? (Of course, I'm assuming that the user |is a valid member of the group!) | |I've looked, but have not been able to come up with a solution (other |than have a separate login entry for the user under a different group.. |but that isn't a viable solution) | |The problem is that newgrp replaces your shell, so that your |execution script no longer runs, and it has no provision (or none |that I've seen) for passing the name of a script to run when it |starts up. I even tried doing a newgrp with the "-" option and then |using .profile to kick on the script, but that results in a lot of |loud complaining (via mail) since the login is not from an interactive |device! | The following script should do what you want: ----------- start of script ----------- #! /bin/sh # grpat - run an at script as an other group. # Usage: grpat group date # Author: L.J.M. de Wit, Fri Jun 29 1990 case $# in 0|1) echo >&2 "Usage: grpat group date"; exit 1;; *) group=$1; shift;; esac (sleep 5; echo at "$@"; cat) | newgrp $group ----------- end of script ----------- The trick is to pass the newgrp command via a pipe the at command to execute plus the script from stdin (passed by cat). The script stored in /usr/spool/at will thus be setuid the group $group, and atrun will execute it for the correct group. The magical "sleep 5" is there to give newgrp a chance to source its [.login|.profile|.cshrc|.whatever], without loosing subsequent input (I don't know the cause, but that seems to be a quirk in many shells). This is also the reason I couldn't use a here document for the newgrp command. Hope this will solve your problem, Leo.
belkin@teecs.UUCP (Hershel Belkin) (07/04/90)
Thanks to all who responded. A few responses indicated that they could do a newgrp to the new group, then run "at" and then newgrp back, and have the "at" job run under the alternate environment. This does not work on my system -- the newgrp always takes the uid/gid from the passwd entry for the user. However, another proposed solution _does_ work... newgrp group << \! ...script to be executed under alternate gid ... ! The above can be put in a script file and run using "at". (I had tried re-direction of stdin, but of course simple re-direction from a file belongs to the current shell, so this doesn't work! The above solution seems so obvious now :-) -- +-----------------------------------------------+-------------------------+ | Hershel Belkin hp9000/825(HP-UX)| UUCP: teecs!belkin | | Test Equipment Engineering Computing Services | Phone: 416 246-2647 | | Litton Systems Canada Limited (Toronto) | FAX: 416 246-5233 | +-----------------------------------------------+-------------------------+