Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • G gvfs
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 425
    • Issues 425
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 23
    • Merge requests 23
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • gvfs
  • Issues
  • #515
Closed
Open
Issue created Sep 08, 2020 by Alexander Larsson@alexlDeveloper

gvfs peer-2-peer incompatible with flatpak network isolation

If you run a flatpak:ed app with gvfs access, but with no network access you will get something like:

gio: cdda://sr1/: Error while getting peer-to-peer dbus connection: Could not connect: Connection refused

This is because on linux, gvfs-daemon always sets USE_ABSTRACT_SOCKETS, which makes it pass back dbus addresses for the p2p connections which are abstract sockets. However, abstract sockets are tied to the network namespace, so any kind of network isolation (even partial) in the app will make connections to the abstract socket break.

The chances of fixing this in the kernel is slight, however abstract sockets are not really very useful these days. They are mainly used to avoid having leftover sockets on the disk after reboot. These days that can be avoided by using tmpfs:es like /run for such sockets, which means we have full access to the regular fs namespaces support.

If we just drop USE_ABSTRACT_SOCKETS it will instead use sockets in /tmp, which is also a problem for isolated apps (as /tmp is per-app). So, I propose that we change that so the daemon creates the p2p sockets in something like /run/user/$uid/gvfds/ instead. Then apps that want to access this can ask for --filesystem=xdg-run/gvfsd access.

CC @hadess

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking