dynamically updating sudoers to allow users different commands at different times? good idea or bad?
Rahul
some comments on my approach.
We use the PBS-Torque scheduler here that allows people to sumit jobs to
a fairshare queue on our cluster. Normally the scheduler handles
previlages so that everyone can only kill his own jobs using the command
"qdel".
Root, though can kill anybody's jobs.
Now, for some "unusually pesky" jobs that refuse to obey a "qdel" the
scheduler provides a -p (purge) option that can be excercised.
"qdel -p foojobnumber" is a last resort command. qdel usually allows only
root to excercise the -p option.
I see no harm in allowing users too to "purge" jobs provided they only
purge their own jobs.
I can add to sudoers this snippet:
"usergroup ALL=/usr/local/bin/qdel -p"
But that would allow anybody to kill anybodys jobs! Bad idea.
I can easily extract lists like so:
foouser "jobnumber1 jobnumber2 ..."
baruser "jobnumber3 jobnumber4 ..."
Can I somehow create a "dynamic" sudoers with the lines:
foouser ALL=/usr/local/bin/qdel -p jobnumber1"
foouser ALL=/usr/local/bin/qdel -p jobnumber2"
baruser ALL=/usr/local/bin/qdel -p jobnumber3"
baruser ALL=/usr/local/bin/qdel -p jobnumber4"
etc.
What's the best approach? Or is this an obvous security hole in some way?
Would I have to update sudoers with a cron job (job numbers change not
faster than say 10 minutes)? Or should I generate a wrapper around
"qdel"?
--
Rahul
Tim Greer
As long as the commands/rules themselves are acceptable and safe (as
safe as some can be), then having them only available at different
times of the day to specific users, should only add a layer of
security. Just like only allowing access to a vital service to
specific sources at specific times can be a good idea. The question of
a wrapper for some commands is more relevant to the function than
automation, of course, but anything that poses a direct issue, I'd
consider not enabling or find a safer alternative. Otherwise, I'd
certainly consider a wrapper, or a configuration that denies unexpected
or unchecked arguments to be passed.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
Rahul
@newsfe03.iad:
> As long as the commands/rules themselves are acceptable and safe (as
> safe as some can be), then having them only available at different
>
Thanks Tim. Within the cron job I'm probably going to add a check:
"visudo -c -f /tmp/sudoers.new" and then copy this file to /etc/sudoers
only if it exits with a 0 error code. Don't want to accidently screw up
sudoers.
Ususally I change it via visudo alone which guards against bad sudoers.
--
Rahul
Tim Greer
Excellent idea.
Chris Davies
> I have a tricky problem that I am trying to solve with "sudo" and wanted
> some comments on my approach.
> Can I somehow create a "dynamic" sudoers with the lines:
> foouser ALL=/usr/local/bin/qdel -p jobnumber1"
> foouser ALL=/usr/local/bin/qdel -p jobnumber2"
> baruser ALL=/usr/local/bin/qdel -p jobnumber3"
> baruser ALL=/usr/local/bin/qdel -p jobnumber4"
> What's the best approach? Or is this an obvous security hole in some way?
A much safer approach that doesn't require regular tweaking of
/etc/sudoers is to write a script that checks the parameters and then
calls your qdel. That script can be put into /etc/sudoers and called by
your user population instead of qdel.
If the script is really clever, it could look to see if it's running
as root and, if not, call itself with sudo. That way you can put the
script into the users' PATH and not even bother to have to tell them
about using sudo.
Chris