Comment 1 for bug 1973321
Revision history for this message
| Alberto Mardegan (mardy) wrote Re: snaps dont't start when current working directory is on sshfs | #1 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Update: none of the solutiones mentioned above work, unfortunately.
The problem is that the FUSE kernel module not only checks the effective user ID, but also the real and saved one:
https:/
As a privileged process, we can set all of the user and group IDs to arbitrary values, and can therefore pass this FUSE check; but once we do, there's no way to get back to being a privileged process, and therefore this is one of the last operations snap-confine performs before executing the desired program.
One option that we might want to investigate is setting all the needed capabilities on our process at startup (while we are still root), set the SECBIT_KEEP_CAPS bit, and then drop all our user IDs to the user ones. As long as we have all the capabilities set, we should be able to perform all the operations we need to; and then capabilities would be normally lost when we call execve().