permissions on a filesystem
in [General Linux]
|
From: Rahul on 14 Feb 2010 10:29 Michael Black <et472(a)ncf.ca> wrote in news:Pine.LNX.4.64.1002140124310.12809(a)darkstar.example.net: > But I can't imagine any situation where only one person could create > files, but everyone could delete them. The deletion is the one that > needs the most control, since otherwise someone can delete by accident > or maliciously. There's no reason for someone to have a monopoly on > creating files when everyone else can delete it as they desire. The > later negates the former. > Thanks for all the tips. Ok, the reason I got thinking along this line: 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 14 Feb 2010 10:30 unruh <unruh(a)wormhole.physics.ubc.ca> wrote in news:slrnhnej50.6t7.unruh(a)wormhole.physics.ubc.ca: > No. By "user" I presume you mean the owner of the directory. Yes. My bad. > The group r on the directory means anyone can read the names of files > in the directory, the w, means anyone in the group can put new names > into the directory (ie create a file) and x means anyonei in group can > get at the files to do something with them, and the t means only the > creator of the file can remove it from the directory. . I know those. Was looking for a workaround to do something more exotic (if feasable). -- Rahul
From: Rahul on 14 Feb 2010 10:34 J G Miller <miller(a)yoyo.ORG> wrote in news:1266113061_137(a)vo.lu: > This is a very strange scenario so it begs the question why would you > want such a thing to be possible? Agreed that it is strange. I posted a more detailed description of why. In this specific case: deletion happens to be a safer risk that I am willing to assume but not creation. And deletion is essential to the goal. > But how about this possible solution -- the other users have read and > write permissions to the directory so they can see and delete files, but > they have a quota set for them on the file system where the directory is > located which is 0 (soft and hard limit), so that way they cannot create I suspect quotas are on the FS level? The /home is mounted and all users have dirs under it. So a zero quota would hamper the ability of a user to create files in his own home dir as well. -- Rahul
From: Rahul on 14 Feb 2010 10:35 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. -- Rahul
From: Rahul on 14 Feb 2010 10:35
Aragorn <aragorn(a)chatfactory.invalid> wrote in news:hl8mhd$ihv$1 @news.eternal-september.org: > Not to mention a very dangerous one! :-) > Why dangerous? -- Rahul |