From: Rahul on
Aragorn <aragorn(a)chatfactory.invalid> wrote in
news:hlap9j$i1m$2(a)news.eternal-september.org:

> Yet I do not understand the logic behind your requirement. Perhaps if
> you were to elaborate more on why you are asking for this odd
> solution, people might be able to offer you ideas for a better
> approach?

Sure. Here goes:

############################
# Many users submit jobs on our scheduling system (openpbs). Normally
# users can delete their own jobs via a "qdel" command from the
# scheduler suite. But, once in a while it requires a stronger "qdel
# --purge". Now the "qdel --purge" binary is so designed that only root
# can use the -- purge option. As a workaroud I wrote a bash script that
# runs every so often via cron and:
#
#
# Checks a "jobstokill" dir for each user for a file of the form "kill*"
# e.g. kill12345 etc. (job num = 12345)
#
# Then it checks who owns that job. Once it confirms that it is the same
# user whose "jobstokill" dir it found the kill12345 it then it kills
# the job with "qdel --purge". To make sure people can't kill each
# others jobs that dir has write perms only for owner. So far so good.
#
# Now that script would then ideally clear the killfile for the job
# that it just deleted. But by the principle of least privilages I'm not
# running killjobs as root. It's in the user group but as a "pbsadmin"
# user. (I did give "pbsadmin" schedular admin privilages but that's a
# relatively restricted power than generic root). But that also means
# that pbsadmin cannot delete files in the "jobstokill" dir as it ought
# to.
#
# Now if I just add write permissions on "jobstokill" for the whole
# users group anyone could write killfiles in each others dirs and play
# mischief. That would be bad. Deleting a killfile in another users dir
# is not such a dangerous op. (it would b even better if I could prevnt
# that too!)
#
#
# In an ideal world though I'd like: "user has the right to make files
# and pbsadmin has right to delete files". But then again, that's a
# pretty exotic need too!
#
# [For some other reasons I'd like to retain pbsadmin in the users
# group. Changing that is an option but will break other scripts.]
###############################





--
Rahul
From: Rahul on
Stan Bischof <stan(a)newserve.worldbadminton.com> wrote in news:4b783310$0
$1647$742ec2ed(a)news.sonic.net:

> So- direct answer to your specific question is "no"
> but you can tack on ACL's to get what you want.
>

Thanks guys. It seems ACL's are my best bet. (I'll have to remember to do
no_acl on the nfs clients for performance reasons)

--
Rahul
From: John Hasler on
Rahul writes:
> Now that script would then ideally clear the killfile for the job that
> it just deleted. But by the principle of least privilages I'm not
> running killjobs as root.

"Least privileges" means a few as necessary to do the job. You're being
paranoid. Just run the thing as root and be happy (or else use ACLs).
--
John Hasler
jhasler(a)newsguy.com
Dancing Horse Hill
Elmwood, WI USA
From: Mark Hobley on
Aragorn <aragorn(a)chatfactory.invalid> wrote:
> Because with a suexec implementation you would be giving root privileges
> to every user

You don't have to suidexec root, you can suidexec user, which is what I
suggested. This gives everyone permission of that user.

> all of those users would in theory also be able to delete files
> in "/etc", "/bin", "/usr", et al. Not very wise.

Not unless the delete command was suidexec root. I said suidexec user. This
will work just fine.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

From: Maxwell Lol on
Aragorn <aragorn(a)chatfactory.invalid> writes:

> Because with a suexec implementation you would be giving root privileges
> to every user,


It could be setuid to the owner of the directory, not root.
It should be a special UID in any case.