Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: firefox (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/1973321
Title:
snaps don't start when current working directory is on a remote FS
(sshfs, NFS)
Status in snapd:
Triaged
Status in firefox package in Ubuntu:
Confirmed
Status in thunderbird package in Ubuntu:
Confirmed
Bug description:
All snaps fail to start when the current working directory is under a
sshfs tree:
/tmp/test$ hello-world
cannot open path of the current working directory: Permission denied
The reason is that sshfs by default disallows the root user (or any
user other than the one who created the mount) from accessing the
mounted file system, and snap-confine is a setuid program which before
dropping its privileges tries to open the current working directory
and terminates if that operation fails:
In sc_preserve_and_sanitize_process_state():
proc_state->orig_cwd_fd =
openat(AT_FDCWD, ".",
O_PATH | O_DIRECTORY | O_CLOEXEC | O_NOFOLLOW);
if (proc_state->orig_cwd_fd < 0) {
die("cannot open path of the current working directory");
}
There are workarounds for this situations: one can add the
"user_allow_other" option to /etc/fuse.conf and call sshfs with the
"-o allow_root" option, and this will allow snaps to start, yet it's a
suboptimal experience.
Possible solutions:
A) Move this part of code a bit later, after having dropping the privileges.
B) Drop the privileges before making this call, and restore them afterwards.
C) Use get_current_dir_name() to get the directory name if openat() fails,
then restore it using chdir().
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1973321/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
