1

Even super root dosen't have acces to this folder/File .

┌─[root@parrot]─[/home/kali_37]
└──╼ #updatedb
/usr/bin/find: '/run/user/1000/doc': Permission denied
┌─[root@parrot]─[/home/kali_37]
└──╼ #ls -ld /run/user/1000/doc
ls: cannot access '/run/user/1000/doc': Permission denied
┌─[✗]─[root@parrot]─[/home/kali_37]
└──╼ #

I want to see the permision of

└──╼ #ls -ld /run/user/1000/doc
ls: cannot access '/run/user/1000/doc': Permission denied
┌─[✗]─[root@parrot]─[/home/kali_37]
└──╼ #

But it returned with ouptput above , still don't have permission to see permission .

Bodo
  • 9,287
  • 1
  • 13
  • 29
subash rimal
  • 11
  • 2

2 Answers2

0

/run/user/$UID is, as you realized, a bit different from other directories. It's used for sandboxing applications so that they have limited access to the file system. Because the files are not copied there but just referenced, file permissions cannot be used as is.

The directory is mounted as tmpfs and it resides primarily on memory. That is how access can be denied to the root user. The resource corresponds to somewhere on memory that is being used. No doubt, there's a way to bypass that as root but the good news is you probably don't need to.

You can just run ls as the unprivileged user with the uid 1000.

If you're interested in manipulating the mechanism behind, there are 2 subjects to research:

toraman
  • 598
  • 4
  • 14
0

How to fix this issue on Ubuntu 22, as I just encountered the same - even root cannot access the path /run/user/1000, which might be solved by wiping the harddrive and reinstalling Linux..

And even if I tried to write ls -lah /run/user/1000/ I could see all files and folders there no problem - even without sudo this was working.

But you may add a "prunepath" to tell updatedb to ignore a path. In my case, this solved the issue:

sudo updatedb --prunepaths='/run/user/1000'

And now I can run locate fine.

alexpanter
  • 1,222
  • 10
  • 25