Create a symbolic link to a file I can’t access

permissionssymlink

[Disclaimer: there's no malicious intent to this question, I'm trying to understand the ln -s command for a school project]

Say I have a file system with my home folder, /home/anna. /home/bob is a folder I can't access, with a file I can't access, foo.txt

Can I successfully run ln -s /home/bob/foo.txt in my home folder? Is it correct to assume that if I can, it will produce a link I can't access (with the same permissions as foo.txt)?

What if I DID have read privileges on foo.txt, just not access to /home/bob?

What about the reverse case, where I could access /home/bob but not read foo.txt?

Best Answer

Yes, you can create a symbolic link to any location.

Can I successfully run ln -s /home/bob/foo.txt in my home folder? Is it correct to assume that if I can, it will produce a link I can't access (with the same permissions as foo.txt)?

Correct. The access restrictions of the target file apply. If you create a symlink to a restricted resource, you simply won't be able to access it. It is not even required that the target file actually exists.

A demo:

$ ln -s /etc/shadow foo
$ file foo
foo: symbolic link to /etc/shadow
$ cat foo
cat: foo: Permission denied

$ ln -s /etc/nonexistent bar
$ file bar
bar: broken symbolic link to /etc/nonexistent

What if I DID have read privileges on foo.txt, just not access to /home/bob?

If you don't have permissions on the parent directory, you can't access the contained file. So with a symlink you still wouldn't be able to access it. Creating a symlink doesn't affect the permissions.

What about the reverse case, where I could access /home/bob but not read foo.txt?

Again, you can create a symlink to it, but not access the file.

Related Solutions

ACL, ls, “permission denied” and a lot of questionmarks

The /home/alice/ directory needs executable access for the user accessing it.

EDIT: BTW, the question marks are there to indicate that ls can't get the permissions on the file.

Unable to stat symbolic link to file

Your answer lies in the first output you provided:

$ stat /home/jzhu/other
  File: `/home/jzhu/other' -> `/root/other/'

This shows that /home/jzhu/other is a symlink to /root/other.

So basically to access anything in /home/jzhu/other/ you are going to need access to /root/other. This means that your user must have execute permissions on both /root and /root/other.

Next lets go on to this command:

$ stat /home/jzhu/other/
stat: cannot stat `/home/jzhu/other/': Permission denied

The reason why this fails and the one above works is because of the trailing /. On any command which works with a path, if the final component of that path (eg: other) is a symlink, and the path ends with a trailing /, then any system calls to operate on that path will try to dereference the symlink, and operate on what the symlink points to instead of the symlink itself.

Solutions:

There are 2 possible solutions to this.

1. Change permissions on `/root/other`:

As mentioned, add execute capability to both /root and /root/other. You can do this with basic or extended filesystem attributes.

You can add the jzhu user to the root group (usermod -a -G root jzhu) and add group execute to the path (chmod g+x /root; chmod g+x /root/other).
This isn't an ideal solution as it grants your access to anything restricted to the root group.
Use filesystem ACLs.
```
setfacl -m u:jzhu:x /root
setfacl -R -m u:jzhu:x /root/other
setfacl -d -R -m u:jzhu:x /root/other
```
This makes it so that your specific user gets execute access to /root/other and anything inside it.
It's still not ideal as if these resources are shared, they shouldn't be in root's home directory.

Note that in both these solutions we only grant the execute (x) bit. The execute bit is needed on a directory for a user to access anything inside that directory. However you also need the read (r) bit to be able to list (ls) the directory. Meaning that without the read bit, you'll have to know exactly where in /root/other the files are. If you want to allow read, just change the x in the last 2 setfacl commands to rx (for example, -m u:jzhu:rx).

2. Move the resources outside `/root/other`.

This is the preferred solution. You can either get rid of the symlink at /home/jzhu/other and create a directory in it's place, or put them in a shared location somewhere else on the system (without knowing what it is, I can't recommend a good location though).

The reason this is the preferred solution is that if these resources are shared among users, then they don't belong to a specific user and shouldn't be in that user's home directory.