Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mountpoint /run/media/$USER always with root ownership #461

Open
amalgame21 opened this issue Jan 1, 2023 · 10 comments · May be fixed by #475
Open

mountpoint /run/media/$USER always with root ownership #461

amalgame21 opened this issue Jan 1, 2023 · 10 comments · May be fixed by #475
Labels
desktop usage on desktop environments enhancement An issue to improve current behavior wip work in progress
Milestone

Comments

@amalgame21
Copy link

After reboot, running tomb open example.tomb -k example.tomb.key, it mounts on /run/media/$USER which with root ownership. As a normal user, somehow I cannot use the bash auto-completion to cd into the /run/media/$USER/example, I have to type the absolute path to cd into that. So every time I just use sudo chown $USER:$USER /run/media/$USER to change the ownership of that mountpoint (I do not know if it impact the security) so I can use the bash auto-completion. However after a reboot, this problem happen again. Is it written by design for security? Thank.

@amalgame21
Copy link
Author

Sorry let me re-describe the issue.

I found that the problem should be after reboot, /run/media/$USER is removed, leaving only /run/media in the system, and tomb open will recreate /run/media/$USER will 711 permission.

Switch it to 755 manually should be fine, but I don't know if it is security concern by design.

I cannot find anything about it in the source code mount_tomb() section. So I have no idea why it created with 711 permission.

@amalgame21
Copy link
Author

Created a /media folder to use tomb open and all problem solved.

@Narrat
Copy link
Contributor

Narrat commented Jan 3, 2023

See the comments to this commit: 843b7fd
It was different and changed somewhere on the road. I had planned to look into this, but it was kinda forgotten. As I was the only one who was "bothered" by it :D

@Narrat
Copy link
Contributor

Narrat commented Jan 3, 2023

And regarding /media: Using this location has some other security related implications. One of the reasons it got in general abandoned in favour of /run/media/<user>

@jaromil jaromil reopened this Jan 4, 2023
@jaromil
Copy link
Member

jaromil commented Jan 4, 2023

hi @amalgame21 ! thanks for the report and @Narrat for keeping track of this issue through earlier comments. I would like to look into this and improve if possible, perhaps just a non-recursive chown on mount dir in /var/run ?

@Narrat
Copy link
Contributor

Narrat commented Jan 4, 2023

Maybe. At least this was done in the past?
What bothers me still, is why it seemed to work with chown'ing the file inside the tomb. Will try to do some test scenarios this week.
I also remember that it made a difference if /run/media/<user> was already existing (due to mounting an USB drive or else) or not.

@Narrat
Copy link
Contributor

Narrat commented Jan 7, 2023

Mounting in run/media seems to involve ACL (Access Control Lists).
Mounting with tomb produces the following dir structure: run/media/$user/<mount>
And the dir $user has the following permissions:

/run/media/
$  ls -l
insgesamt 0
drwx--x--x 3 root root 60  7. Jan 20:12 testuser

After removing the folders and mounting something with for example udiskctl the dir structure is the same: run/media/$user/<mount>.
But the permissions differ:

/run/media/
$  ls -l
insgesamt 0
drwxr-x---+  3 root root  60  7. Jan 20:26 testuser

There is the additional + which tells us about existing ACL:

/run/media/
$ getfacl testuser 
# file: user
# owner: root
# group: root
user::rwx
user:testuser:r-x
group::---
mask::r-x
other::---

@amalgame21
Copy link
Author

@Narrat Yes, that's also what I discovered between the mount point permission of udiskie mounting USBs and tomb mounting tomb files.
I did not know what the + stand for in the udiskie case, but it seems magically make the mount point readable to users other than root, although the permission was set to 750.
ACL is a new word to me, thanks for mentioning this.

@jaromil
Copy link
Member

jaromil commented Jan 8, 2023

I wonder, shall we then use setfacl on the /run/media/$USER/$tombname mount folder with something like:
setfacl --set=u::rwx,u:$USER:rwx,g::---,g:$USER:---,m::---,o::---
perhaps printing it in log messages to ease adjustments by hand?

@Narrat
Copy link
Contributor

Narrat commented Jan 10, 2023

Imo yes. But should it only be used on /run/media? Or is there also a gain if it used on other mount locations? And there should probably a check if the filesystem supports ACL.
Regarding the command itself. Shouldn't setfacl --modify=u:$USER:rwx be enough? Dunno about setting the group, because that varies from distribution to distribution. Debian and such create a group for the username. Others have a generic group users. And if I open something with secrets only I want to be able to see the contents.

Narrat added a commit to Narrat/Tomb that referenced this issue Jun 23, 2023
Namely /run/media/$USER.
The mount point itself is owned by root, therefore one needs to know the name of the mountpoint to change to the location.
Other tools for mounting media like udisksctl set ACL to allow the owner to use it normally (autocompletion and such).

Fixes dyne#461
@Narrat Narrat linked a pull request Jun 23, 2023 that will close this issue
@jaromil jaromil added wip work in progress enhancement An issue to improve current behavior desktop usage on desktop environments labels May 11, 2024
@jaromil jaromil added this to the 3.0 milestone May 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
desktop usage on desktop environments enhancement An issue to improve current behavior wip work in progress
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants