Symlink giving “Permission denied”… to root

I wrote a simple script to automate creating a symbolic link.

Simple enough; get today’s date and make a symlink. Ideally run after midnight with -f so it just updates it in-place.

This works just fine! . for my user.

Notice that it works fine, all the permissions are world-readable, everything looks good.

But if someone else wants to use this link (we’ll say, root, but any other user has this problem), something very strange happens:

I am at a complete loss as to why this is. I’ve also tried creating the links with ln -s -n -f (not that » —no-dereferencing » is very well-explained), but the same issue appears.

1 Answer 1

Since /tmp usually has the sticky bit set, the access to /tmp/today is denied because of protected_symlinks . You can disable this protection by setting

A long-standing class of security issues is the symlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given symlink (i.e. a root process follows a symlink belonging to another user). For a likely incomplete list of hundreds of examples across the years, please see: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp

When set to «0», symlink following behavior is unrestricted.

When set to «1» symlinks are permitted to be followed only when outside a sticky world-writable directory, or when the uid of the symlink and follower match, or when the directory owner matches the symlink’s owner.

This protection is based on the restrictions in Openwall and grsecurity.

Permission to make symbolic links in Windows 7?

How can I grant a particular user the permission to create symlinks in Windows 7?

I’ve searched through «Group Policy» and Google, but haven’t found anything.

On a side note, is there a way to search through everything in Group Policy Editor? The filters only seem to work on particular subtrees. I never actually found anything using the filters.

2 Answers 2

Open the Local Group Policy Editor : Run > gpedit.msc . If that doesn’t work try secpol.msc (Note, Windows Home users might need to enable group-policy-editor first).

Go to (Windows Pro users might don’t see the first two items ) :

Computer configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment and edit the Create symbolic links .

Add the user or group that you want to allow to create symbolic links.

If you’ve added your own user account, you need to log out and log in back in for the change to have an effect.

Note: This setting has no effect on user accounts that belong to the Administrators group. Those users will always have to run mklink in an elevated environment (as Administrator) because of the way UAC removes privileges when creating an non-elevated access token. There is a handy Excel reference sheet for finding group policy settings: Group Policy Settings Reference for Windows and Windows Server

Permissions Denied to Symbolic Links #12

Comments

soamaven commented Mar 14, 2016

I can mount a remote directory to /home/user/mnt and can see symbolic links via ls of that directory, but I cannot r,w, or x the links. I mount using the code below, with RSA key pairs for authentication.

The remote folder is mounted without error. I can list and read the file file.txt as expected.
When I try to ls and read file_symlink.txt I get:

I can see it, but am denied permission.

I have tried many different sshfs options. Same behavior when I try running via sudo also.

The glaring inconsistency to me is that ls -alh file_symlink.txt shows the symlink as a regular file, rather than as a link. I think this is a result of the follow_symlink option, but when I mount without this option, I can still read the original file.txt as before, but when I go to access file_symlink.txt I get:

ls first says the file doesn’t exist, but then lists the link with the link specification?

If anyone knows enough about sshfs to clarify the behavior I am seeing, that would be awesome! Thanks!

versions:
Fedora 23 4.4.3-300.fc23.x86_64
SSHFS version 2.5
FUSE library version: 2.9.4
fusermount version: 2.9.4
using FUSE kernel interface version 7.19

The text was updated successfully, but these errors were encountered:

soamaven commented Mar 20, 2016

@Nikratio curious if this is expected behavior or not. I haven’t found a good work around yet; still actively looking. Thanks!

soamaven commented Apr 26, 2016

Still having this issue. if anyone can provide some insight or help it would be greatly appreciated :/

Nikratio commented Jun 5, 2016

It’s a little difficult to follow your description. What is the target of the symlink? What result do you get when you ssh into the system and do ls on the symlink?

Nikratio commented Jun 5, 2016

Also, with what uid are you logging into the server? Do you actually have permission to read the file that the symlink points to? Note that it’s not world-readable.

soamaven commented Jun 5, 2016

The symlink target is a text file, in the same directory.

when I ssh into the system and do ls, i get
[user@local] $ usls -alh file_symlink.txt
lrwxrwxrwx 1 user users 12 Feb 3 11:04 file_symlink.txt -> file.txt

I am logging into the system with the same uid as the local machine, so 1000 (the uid is 1000 on local, and 1001 on remote), and yes, I do have permissions to read the file when logged in under ssh.

[user@remote]$ ls -alh file.txt
-rwxr-xr-x 1 user users 6.6K Mar 10 16:00 file.txt

Nikratio commented Jun 5, 2016

In that case there would need to be a problem with transferring the permissions (which is unlikely). Can you please confirm the output of ls -l file_symlink.txt after mounting with follow_symlinks ? According to your first post it is -rwxr-x— , while it should be -rwxr-xr-x . Finally, are you sure you are copying & pasting correctly, or are you using a strange version oif ls ? There is a weird dot after the permission in your first post, and you seem to be calling usls instead of ls in your most recent post.

Nikratio commented Jun 5, 2016

For reference, when you use follow_symlinks , then ls will never show you a symlink if the target exists. That is intentional, because symlinks are followed. I would have to check the source to determine what’s supposed to happen if the target does not exist.

soamaven commented Jun 5, 2016

[user@local]$ sshfs -o allow_other,uid=1000,gid=100,follow_symlinks user@remote:/remote_dir

/mnt
[user@local]$ ls -l

/mnt/file_symlink.txt
-rwxr-xr-x. 1 user users 6.6K Mar 10 16:00 mnt/file_symlink.txt
It looks like the symlink is followed properly, the symlink is not listed as a link.

The two systems are not the same Linux OS. Maybe that can explain the differences in the ls outputs and the period? I don’t know about that. but I am copying correctly. I am definitely simply using ls on both machines however. The machine with the period output is Fedora, the machine without it is a Synology NAS system with its a Synology Linux distro.

Nikratio commented Jun 5, 2016

Well, so it seems now you’re getting a different output than when you reported this. So can you please also confirm that the problem is still present?

soamaven commented Jun 5, 2016 •

Sorry, this issue is a few months old, and I have been using a work-around (rsync between locals and the remote). The work around is responsible for the different permissions output. The files permissions are correct in this case only because I had copied the file.txt from local to remote and I forgot that I had done this and permissions were preserved.

I am using a proprietary program, which creates symbolic links during run-time, and it can’t subsequently access those links. I had thought that this was a problem with sshfs mouting, But now that I am looking at this again, it looks like the symbolic links are being created by the program with the wrong permissions in the first place.

Using the proprietary program, the file permissions are as before:
-rwxr-x—. 1 user users 6.6K Mar 10 16:00 mnt/file_symlink.txt

Can I create symbolic links to files when the directory is mounted via sshfs? After mounting, I tried
[user@local]$ ln -s /home/user/mnt/file.txt /home/user/mnt/file_symlink.txt
and got :
ln: failed to create symbolic link ‘/home/user/mnt/file_symlink.txt’: Operation not permitted

Nikratio commented Jun 6, 2016

Can you create a regular file with the same name? What happens if you do rm file_symlink.txt followed by echo foo > symlink.txt ?

soamaven commented Jun 16, 2016 •

I think so. I did this:

After, I also tried this:

but when i ls the directory, it shows up, see the image below. Unmounting, and remounting still shows the same.

(*Note: The uid in the screengrab is 1038 — I have been using uid 1000 in the issue descriptions for generality/abstraction in the descriptions, but actually using 1038 locally since that is my remote uid on the server. Speaking of, the server is a Synology NAS system Diskstation Manger OS, if that is useful)

EDIT: Changed «symlink.txt» to «file.txt» to accurately represent problem.

Nikratio commented Jun 16, 2016

And is this mounted with —follow-symlinks ? If yes, does it work if you mount without that option?

soamaven commented Jun 27, 2016 •

Yes that was with —follow-symlinks . I unmounted and remounted without this option. This made the previous symlinks disappear when using ls in that directory, so the . situation disappears. also a bit wierid.

I remounted as follows

Can’t find the file, this is expected: it hasn’t been created yet. Create it now:

I am able to create the symlink without —follow-symlinks but then when I go to access the file I can’t. I cannot read the symbolic link yet I can see symlink using ls -alh file_symlink.txt .

Nikratio commented Jul 1, 2016

Very odd. I just noticed that in your second to last message, the ls command actually lists the file as . It seems there is clearly something not right. Unfortunately I can’t reproduce any of this on my system.. I don’t think I’ll have time to do anything about this for the foreseeable future.

soamaven commented Jul 1, 2016

TL;DR I had a typo before with and . sshfs between two of my Fedora machines seems to work as expected, I get different behavior between Fedora and Synology NAS where I want to use sshfs . Thanks for your help!

I had a typo with ls outputting . Sorry, tried to generalize the commands and scrub personal file data (very sorry for the inconsistencies! Edited!), I would not direct attention to that typo. I quadruple checked for any other inconsistencies on this update and tried all these commands twice. Again sorry.

I have tried the following commands with follow-symlinks and without on a Fedora(local) Fedora(remote) connection, as below:

File not found, expected. Create it and the symlink now:

Everything works as expected up to here! 😀

Again, on Fedora Fedora, do the same process but with follow_symlinks now:

So the error here, is that with -o follow_symlinks , it tells me I can’t make the soft link. When I list the directory with a wildcard, it somehow knows to look for file_symlink but can’t find it. This is a very specific file name to look for when file* could match nearly anything. I can reproduce the error and get the . following these steps and then ls

/mnt , as in the image below.

I decided to see what the remote machine sees, so I logged into it and did this:

So when making a symlink on the local, it makes the link to the literal path on local, and this is reflected on remote as above (same behavior with -o follow_symlinks and without). When sshfs tries to follow this symlink on the ls command, it can’t; makes some sense. I guess this explains why everything works without -o follow_symlinks .

Now,
When I use these commands on Fedora(local) Synology NAS(remote) I actually get different behavior:
(Note: Other Synology users have reccomended to use -o idmap=user and it stabilizes my connection for whatever reason, another oddity)

This is different behavior than before for mounting without -o follow_symlinks . Notice that mnt/file_symlink.txt can’t be found and is then listed below the read error anyway, which is similar but not exactly the same behavior as Fedora Fedora with -o follow_symlinks .

Doing Fedora(local) Synology NAS(remote) with -o follow_symlinks gives the same behavior as Fedora(local) Fedora(remote) with -o follow_symlinks .

I now believe this is specific to mounting the Synology NAS. Another Synology user describes a similar problem back in 2011.

[Windows] Errno::EACCES: Permission denied @ rb_file_s_symlink #319

Comments

francesco-loreti commented Jul 22, 2018

Errno::EACCES: Permission denied @ rb_file_s_symlink —
(test/migrations/../../lib/generators/public_activity/migration/templates/migration.rb,
C:/Ruby25-x64/lib/ruby/gems/2.5.0/gems/public_activity-1.6.0/test/migrations/001_create_activities.rb)
An error occurred while installing public_activity (1.6.0), and Bundler cannot
continue.
Make sure that gem install public_activity -v ‘1.6.0’ —source ‘https://rubygems.org/’ succeeds before bundling.

The text was updated successfully, but these errors were encountered:

pokonski commented Jul 24, 2018

Thanks @francesco-loreti, will try to reproduce, but I don’t develop on windows so might be tougher to reproduce.

Probably related to #320

pokonski commented Jul 24, 2018

Can you try version 1.6.1? It should fix the problem.

francesco-loreti commented Jul 24, 2018

Not working
ERROR: While executing gem . (Errno::EACCES) Permission denied @ rb_file_s_symlink — (test/migrations/../../lib/generators/public_activity/migration/templates/migration.rb, C:/Ruby25-x64/lib/ruby/gems/2.5.0/gems/public_activity-1.6.1/test/migration s/001_create_activities.rb)

kawamoto commented Nov 2, 2018

I hit similar issue on my mac and linux environment. the problem is gems/public_activity-1.6.x/test/migrations/001_create_activities.rb points to test/migrations/../../lib/generators/public_activity/migration/templates/migration.rb .

Temporary Solution for me:

get source from github like gem ‘public_activity’, git: ‘https://github.com/chaps-io/public_activity’, tag: ‘v1.6.2’

To Maintainers :

it seems packaged gem file on rubygems is little bit broken.

could you check what’s happen in between v1.5.0 and v1.6.0 ?