permissions on a filesystem
in [General Linux]
|
From: Keith Keller on 14 Feb 2010 16:29 On 2010-02-14, Mark Hobley <markhobley(a)hotpop.donottypethisbit.com> wrote: > Rahul <nospam(a)invalid.invalid> wrote: >> >> 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. > > Ok. Why is the purge option needed here? What is happening? I don't know from openpbs, but occasionally on SGE jobs will enter a stuck state, where qdel puts the job into delete state, but the job is not actually deleted. (This usually happens when the node running the job has crashed.) But SGE allows qdel -f to allow a user to forcibly remove his own jobs; apparently openpbs may not. --keith -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information
From: Rahul on 14 Feb 2010 21:18 Keith Keller <kkeller-usenet(a)wombat.san-francisco.ca.us> wrote in news:di6m47xbfo.ln2(a)goaway.wombat.san-francisco.ca.us: > I don't know from openpbs, but occasionally on SGE jobs will enter a > stuck state, where qdel puts the job into delete state, but the job is > not actually deleted. (This usually happens when the node running the > job has crashed.) But SGE allows qdel -f to allow a user to forcibly > remove his own jobs; apparently openpbs may not. > > Yup, exactly that. -- Rahul
From: Aragorn on 15 Feb 2010 01:21 On Sunday 14 February 2010 16:35 in comp.os.linux.misc, somebody identifying as Rahul wrote... > Aragorn <aragorn(a)chatfactory.invalid> wrote in news:hl8mhd$ihv$1 > @news.eternal-september.org: > >> Not to mention a very dangerous one! :-) > > Why dangerous? Because with a suexec implementation you would be giving root privileges to every user, which means that - unless you've got all filesystems containing system files mounted read-only, which in the case of the root filesystem is not exactly an easy thing to accomplish - all of those users would in theory also be able to delete files in "/etc", "/bin", "/usr", et al. Not very wise. -- *Aragorn* (registered GNU/Linux user #223157)
From: Aragorn on 15 Feb 2010 01:23 On Sunday 14 February 2010 16:35 in comp.os.linux.misc, somebody identifying as Rahul wrote... > Aragorn <aragorn(a)chatfactory.invalid> wrote in news:hl83cg$at4$1 > @news.eternal-september.org: > >> The opposite can be accomplished by setting the sticky bit. Then >> everyone can write to the directory, but only the owner of each >> individual file is able to delete his or her files. And well, root >> can always delete everything, of course. > > I know the sticky bit. But this seems the almost opposite need. The sticky bit *is* the opposite of what you want to accomplish - that is what I wrote. 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? -- *Aragorn* (registered GNU/Linux user #223157)
From: Rahul on 15 Feb 2010 03:16
Aragorn <aragorn(a)chatfactory.invalid> wrote in news:hlap58$i1m$1 @news.eternal-september.org: > Because with a suexec implementation you would be giving root privileges > to every user, which means that - unless you've got all filesystems > containing system files mounted read-only, which in the case of the > root filesystem is not exactly an easy thing to accomplish - all of > those users would in theory also be able to delete files > in "/etc", "/bin", "/usr", et al. Not very wise. > Which is exactly why I am trying to avoid a suexec / setsuid solution. I think ACL's are a better option since then my program always runs in a normal user mode. -- Rahul |