Complicated Permission Problem

[Ty Roberts]

I am trying to figure out a way to stop a use from being able to remove or overwrite a soft link with a regular file while all the while being able to read and write to the file that the link references. I have figured that part out fine and it is shown in the example below..

drwxr-xr-x 2 root sys 96 Aug 23 08:41 ./spec
lrwxrwxr-x 1 jdexe jdexe 24 Aug 23 08:41 ./spec/file.link -> ../spec.master/file.real
drwxr-xr-x 2 jdexe jdexe 96 Aug 23 08:36 ./spec.master
-rw-rw-r-- 1 jdexe jdexe 12 Aug 23 08:38 ./spec.master/file.real

The part that makes this complicated is that I would like to allow the JDEXE user to be able to create new directories inside of the "spec" directory but just nothing besides a read / write to the links.

Is there a way to do this with ACLs or some other type of alternative permission mechanism that I don't know about? Or, as I suspect, are we out of luck??

Thanks for all your help,
Ty

[Carles Viaplana]

Hello,

If you change link owner to root:sys, jdexe won't be able to modify link but will be able to create new directories inside spec directory and access to /spec.master/file.real under file.real configured permissions (-rw-rw-r-- jdexe jdexe).

I hope this is you need.
Regards,

Carles

[Ty Roberts]

Thanks for the response but that does not work. If the owner of the link is root:sys it will still allow the jdexe user to remove the link. I thought that links inherit the permissions of the file that they are linking to... see below

wcores04(/tmp/link_test/spec)$ ll
total 0
lrwxr-xr-x 1 root sys 24 Aug 23 09:12 file.link -> ../spec.master/file.real
wcores04(/tmp/link_test/spec)$ rm file.link
wcores04(/tmp/link_test/spec)$ ll
total 0
wcores04(/tmp/link_test/spec)$ whoami
jdexe

[RAC_1]

An ability os user to delete a files is controlled by perms on directory under which a file resides. So if the dir has perms for user, but not for a file, he can stil dete a file.
What are the perms on directory where link and file resides. Also, is this file needs to be executable, if not you just keep read perms for group and others.

[Ty Roberts]

RAC,
The permissions for the directories are listed in my initial post. The links don't need to be executable they jsut need to be RW for jdexe but I don't want them to be able to remove the file..

[Greg Vaidman]

Ty,
Not sure why you're seeing what you're seeing... See below

$ find . | xargs ll -d
drwxr-xr-x 3 root sys 96 Aug 23 09:57 .
lrwxr-xr-x 1 root sys 9 Aug 23 09:57 ./link -> real/file
drwxr-xr-x 2 testusr sys 96 Aug 23 09:56 ./real
-rwxr-xr-x 1 testusr sys 39 Aug 23 09:59 ./real/file
$ id
uid=851(testusr) gid=20(users)
$ rm link
rm: link not removed. Permission denied
$ cat link
this is the content of the file "file"
$ date >> link
$ cat link
this is the content of the file "file"
Tue Aug 23 10:04:13 EDT 2005

[Ty Roberts]

Greg, can you give me the ownership and permissions of the folder that houses "link"? That was we can see if we are comparing apples to apples.

[Ty Roberts]

Greg, sorry I didn't see what I was looking for till I posted the last post.

drwxr-xr-x 3 root sys 96 Aug 23 09:57 .

I got the same results as you did when "root" owned the parent dir of link. Try to change the ownership of the parent dir to your test user and then try to remove the link.

[Rodney Hills]

Could you use the "sticky" bit on the permissions to the folder?

You can create a folder and give "other" read/write/exec permission, but with the sticky bit, a user can only create new files or do operations on files "owned" by the themselves. This should protect other objects under your "spec" directory

To assign sticky bit-
chmod 1777 spec

HTH

-- Rod Hills

[Ty Roberts]

Rodney, I thought that you were onto something here.. but check out the following output. I think I had everything setup right but it still allowed the jdexe user to remove a file (in this case a link) that was owned by root.

wcores04(/tmp/link_test)$ find . | xargs ll -d
drwxr-xr-x 4 root sys 96 Aug 23 08:36 .
drwx-----T 2 jdexe jdexe 96 Aug 23 10:26 ./spec
drwxr-xr-x 2 jdexe jdexe 96 Aug 23 08:36 ./spec.master
-rw-rw-r-- 1 jdexe jdexe 22 Aug 23 10:25 ./spec.master/file.real
lrwxr-xr-x 1 root sys 24 Aug 23 10:25 ./spec/file.link -> ../spec.master/file.real
wcores04(/tmp/link_test)$ cd spec
wcores04(/tmp/link_test/spec)$ id
uid=145(jdexe) gid=116(jdexe) groups=103(icon),107(jdepod),108(wtech),109(jdecomm),110(jdeconv),111(edi),123(mqm)
wcores04(/tmp/link_test/spec)$ touch test.file
wcores04(/tmp/link_test/spec)$ ll
total 0
lrwxr-xr-x 1 root sys 24 Aug 23 10:25 file.link -> ../spec.master/file.real
-rw-rw-r-- 1 jdexe jdexe 0 Aug 23 10:27 test.file
wcores04(/tmp/link_test/spec)$ rm file.link
wcores04(/tmp/link_test/spec)$ ll
total 0
-rw-rw-r-- 1 jdexe jdexe 0 Aug 23 10:27 test.file

[Ty Roberts]

I just tried the same test with the permissions of spec being the following..

drwxrwxrwt 2 jdexe jdexe 96 Aug 23 10:34 spec

[Greg Vaidman · Accepted solution]

Ty,
That's because your spec directory is owner by jdexe. If you make it owned by root:sys and permissions 1777, that should prevent jdexe from removing root's files. jdexe will still be able to remove his/her own files, though...

--Greg

[Ty Roberts]

Greg, that was the ticket. Now to throw another kink in the chain we just need to test this out when the spec dir is shared with NFS...

Thanks for all the help everyone..

Ty

[Dietmar Konermann]

Mabbe you should set the t-flag on a the spec dir. Then only owners are allowed to delete their own files. Note, that symlinks don't have their own effective ownership/mode!

My idea ist to use only the jdexe group to grant write permission. If the owner of the real file is e.g. root, then deletion is prevented by the t-flag.

Using your example above:

chown root:jdexe ./spec
chmod 775 ./spec
chmod u+t ./spec
chown root:jdexe ./spec.master/file.real

Result would be:

drwxrwxr-t 2 root jdexe 96 Aug 23 08:41 ./spec
lrwxrwxr-x 1 jdexe jdexe 24 Aug 23 08:41 ./spec/file.link -> ../spec.master/file.real
drwxr-xr-x 2 jdexe jdexe 96 Aug 23 08:36 ./spec.master
-rw-rw-r-- 1 root jdexe 12 Aug 23 08:38 ./spec.master/file.real

Give it a try!

Dietmar.

[Dietmar Konermann]

Oops... too late. Should have done refresh before. :)