From: Rahul on 15 Feb 2010 03:19 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 15 Feb 2010 03:20 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 15 Feb 2010 08:03 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 15 Feb 2010 12:08 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 16 Feb 2010 22:44 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.
First
|
Prev
|
Pages: 1 2 3 4 5 6 Prev: Is Debian a fraud ? Next: How can I increase my Xdialog font size? |