I know that chmod cannot change symbolic link permission?
Why is it prohibited?

the link is just a shortcut to the file. it will have the
same permissions as the file it points to except for
operations the only reference the symlink.
you may own the file, and someone else may own the
symlink. they can delete the symlink, but not the original
file. if you make the file read-only to everyone else, they
shouldn't be able to make it writeable with a symlink.

DO YOU KNOW A WAY FOR MAKING A LINK WITH A 755 PERMISSION?
The impossibility to change its permission creates a lot of problem on a web server. I explain you why:

1. symbolic link has only 777 permission ;
2. Many hosts are now installing PHPsuexec as an added security measure.
3. This will affect all of us who use PHPclassifieds in that .htaccess files are not permitted [we used these to turn register_globals off] and CHMOD permissions cannot be set to 777.
4. If I go on symboliclink, it will result in a 500 internal server error when attempting to view them.

This symbolic points to a cgi scripts with 755 permission.
I Permissions on a symbolic link don't really mean anything and if the only permissions that count are the permissions on the file that the link points to, IT SHOULD WORK .

Thank you very much

Permissions on symlinks would simply make no sense at all, only the permissions of the file that they point to is relevant, and that's what linux changes when you chmod a symbolic link.

This is not only true for linux, but also for each other unix (and unix clones) that I've tried.

No.

The problem is not created by symlinks, they existed by more than two decades now and they are a good thing and work ok for everyone, except for phpsuexec, then you can deduct where the bug lies on...

All the smart programs deference symlinks when they need to, instead of blindingly operating over files of the wrong type. It's as easy as to check that the file is a regular file. If it's regular or a dir, then ok, if it's a symlink, deference it and operate as you must. If phpsuexec or whatever php code you use doesn't do it, then you are going to have to do it yourself by wrapping the code into the necessary checks.

There's no point and no logic behind modifying the permissions of a symlink from a conceptual point of view (even if that was possible, which it is not). If accessing to a file was as easy as creating a symlink to it and then changing the permissions of the symlink the linux would be the most insecure os around the world.

It would be like drawing a door in a wall with a pencil and pretending to open it when you don't have the key to the front door.

Poor mee!!! Now I have to edit all again
Oh, it's something formal: For me it's better to draw a door in a wall with a pencil hehe

Thank you very much.

I know this is an old thread but I want to comment anyway... There *are* scenarios in which changing permissions of a link itself, and not what it points to, would be desirable. I have one right now. I need a link that is created in each user's home directory that I don't want them to be able to remove or change in any way. So to me, if a sym link is a file, you should be able to change the filesystem permissions on it.

is a sym link a file? I assume it is, like a 'shortcut' in the Windows world. But if not, please correct me so I understand what it really is, then that may allow me to understand why you shouldn't be able to change it's filesystem permissions. Currently I'm thinking it's a file, it simply points to another filesystem location, but it is itself a separate entity from the location it points to.

Actually the operating system is the one who handles symbolic links. The way to access files is using system calls. The system calls automatically deference the symbolic link (with exception of several system calls designed to manipulate the symbolic links).

The idea of the permissions is to restrict system calls. The few system calls that work with symbolic links don't really need any permissions to work properly and securely so actually symbolic links have no permissions associated with them. That's a good thing because it leaves more free space in the inode to implement fast symlinks (for more information see http://en.wikipedia.org/wiki/Symbolic_link). The permissions that you actually see with "ls -l" are just some information that the kernel generates when the "lstat" system call is invoked on a symbolic link.

You can't do that with a regular file either, if the user has write permissions on a directory they can always remove a file even it is owned by root and 000 perms (the exception to this is if the directory is chmod + t (stickybit), then only the owner can remove the file and that would apply to symlinks as well). The best you can do is make a subdir that they don't have write perms on and put a file in there or add the sticky bit

I found another reason for which it would useful to chmod symbolic links: To change the permissions of busybox symbolic links to stop certain users from been able to su (http://www.cromwell-intl.com/securit...ardening.html: Limit the set of people able to attempt to become root).
Hopefully there is another solution.

As far as 'locking' a file (& in Linux its all files) against changes go, only root (or equiv) can use the chattr cmd http://linux.die.net/man/1/chattr; you'll want the -i flag

Users could still create their own symlinks to busybox, with whatever name they want and whatever permissions they wish.

You should be using ACLs (Access Control Lists) anyway.

Hi,

Thank you very much for your answers and sorry for taking so much time to reply (due the lack of internet connection over the last few days).

chrism01: I don't think that this command will help me as I would like to stop an user from running the su command, which is an existing link to busybox.

i92guboj: Same as above.

sundialsvcs: This is sounds like a good solution but this command doesn't exist on my system and I am not sure how to add it. I am running a ramfs image loaded into RAM (embedded device) and the filesystem is rootfs. I might need to able Tmpfs POSIX Access Control Lists in the kernel but I doubt that will provide me with the command.

Would anybody have any idea how to add setfacl into an image based on busybox?
Is this command come from a package, a kernel option or a busybox option?

Cheers,

Emmanuel

It doesn't look like if Wind River is supporting ACL package.

That's a slightly different qn.
In that case (bear in mind I've only got Solaris in front of me but principle is the same), remove other/world perms from su binary and ensure user is not root or in group owning su eg
As above, for more fine-grained limits, use ACLs if possible. How many users really need to use it.
You could also use sudo after doing the above.