Bug#852696: gvfs-fuse: automatically starts gvfsd and gvfsd-fuse in root user slice

[Laurent Bonnaud]

Package: gvfs-fuse
Version: 1.30.3-1
Severity: normal


Dear Maintainer,

I usually remotely log in (via ssh) as root on a system where gvfs packages are installed and I noticed that a gvfsd process and a gvfsd-fuse process are created for the root user:

# systemd-cgls
Control group /:
-.slice
├─user.slice
│ └─user-0.slice
│ ├─us...@0.service
│ │ ├─dbus.service
│ │ │ └─16957 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslo
│ │ ├─gpg-agent.service
│ │ │ └─15353 /usr/bin/gpg-agent --supervised
│ │ ├─init.scope
│ │ │ ├─31495 /lib/systemd/systemd --user
│ │ │ └─31497 (sd-pam)
│ │ └─gvfs-daemon.service
│ │ ├─17040 /usr/lib/gvfs/gvfsd
│ │ └─17045 /usr/lib/gvfs/gvfsd-fuse /run/user/0/gvfs -f -o big_writes

Those processes are of no use to the root user and therefore the system would be better without them. Would it be possible to prevent the creation of those processes?


-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gvfs-fuse depends on:
ii fuse 2.9.7-1
ii gvfs 1.30.3-1
ii libc6 2.24-9
ii libfuse2 2.9.7-1
ii libglib2.0-0 2.51.0-2

gvfs-fuse recommends no packages.

gvfs-fuse suggests no packages.

-- no debconf information

--
Laurent.

[Michael Biebl]

Am 26.01.2017 um 14:54 schrieb Laurent Bonnaud:
> Package: gvfs-fuse
> Version: 1.30.3-1
> Severity: normal
>
>
> Dear Maintainer,
>
> I usually remotely log in (via ssh) as root on a system where gvfs packages are installed and I noticed that a gvfsd process and a gvfsd-fuse process are created for the root user:
>
> # systemd-cgls
> Control group /:
> -.slice
> ├─user.slice
> │ └─user-0.slice
> │ ├─us...@0.service
> │ │ ├─dbus.service
> │ │ │ └─16957 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslo
> │ │ ├─gpg-agent.service
> │ │ │ └─15353 /usr/bin/gpg-agent --supervised
> │ │ ├─init.scope
> │ │ │ ├─31495 /lib/systemd/systemd --user
> │ │ │ └─31497 (sd-pam)
> │ │ └─gvfs-daemon.service
> │ │ ├─17040 /usr/lib/gvfs/gvfsd
> │ │ └─17045 /usr/lib/gvfs/gvfsd-fuse /run/user/0/gvfs -f -o big_writes
>
> Those processes are of no use to the root user and therefore the system would be better without them. Would it be possible to prevent the creation of those processes?

Those are so-called user service which are started by your systemd
--user instance (pid 31495)

You can mask the service just like regular services:
systemctl --user mask gvfs-daemon.service

This will create
/root/.config/systemd/user/gvfs-daemon.service → /dev/null.

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Simon McVittie]

On Thu, 26 Jan 2017 at 14:54:20 +0100, Laurent Bonnaud wrote:
> I usually remotely log in (via ssh) as root on a system where gvfs
> packages are installed and I noticed that a gvfsd process and a gvfsd-fuse
> process are created for the root user:

I think those are started by D-Bus activation when some root process
(possibly multiple root processes) tries to communicate with them. You
could use `dbus-monitor --system` to find out what is trying to
communicate with them - it might well be something that shouldn't.

Or if you're willing to try dbus from experimental, the dbus-daemon
from that version logs to the Journal with information about which
process was the first to ask for a particular activation.

S

[Simon McVittie]

On Thu, 26 Jan 2017 at 15:19:14 +0000, Simon McVittie wrote:
> Or if you're willing to try dbus from experimental, the dbus-daemon
> from that version logs to the Journal with information about which
> process was the first to ask for a particular activation.

In dbus from unstable, you'll see messages like

Activating via systemd: service name='org.gnome.gvfs' unit='gvfsd.service'

You might be able to guess from other Journal messages around that time
which caller was responsible, but it isn't specifically stated.

From experimental, which is a development branch that will go to unstable
after stretch is released, it'll be more like:

Activating via systemd: service name='org.gnome.gvfs' unit='gvfsd.service'
requested by ':1.42' (uid=1000 pid=1234 comm="dbus-send")

Hope this helps,
S

[Michael Biebl]

Am 26.01.2017 um 18:01 schrieb Simon McVittie:
>>From experimental, which is a development branch that will go to unstable
> after stretch is released, it'll be more like:
>
> Activating via systemd: service name='org.gnome.gvfs' unit='gvfsd.service'
> requested by ':1.42' (uid=1000 pid=1234 comm="dbus-send")

Very nice feature! If only we had that for other triggers (.socket,
.path, etc) as well.

Michael

[Laurent Bonnaud]

On 26/01/2017 15:48, Michael Biebl wrote:

> You can mask the service just like regular services:
> systemctl --user mask gvfs-daemon.service

Thank you for the hint! I did that and we'll see if it stops the creation of the unwanted processes...

--
Laurent.

[Laurent Bonnaud]

On 26/01/2017 18:01, Simon McVittie wrote:

> In dbus from unstable, you'll see messages like
>
> Activating via systemd: service name='org.gnome.gvfs' unit='gvfsd.service'

My system does have dbus from experimental and indeed I see the following in the logs:

janv. 26 13:55:02 hostname dbus-daemon[16957]: [session uid=0 pid=16957] Activating via systemd: service name='org.gtk.vfs.Daemon' unit='gvfs-daemon.service' requested by ':1.1' (uid=0 pid=16956 comm="appstreamcli refresh-cache ")

Do you think I should reassign this bug to the appstreamcli package?

--
Laurent.

[Simon McVittie]

Control: reassign 852696 appstream

On Thu, 26 Jan 2017 at 19:27:19 +0100, Laurent Bonnaud wrote:
> janv. 26 13:55:02 hostname dbus-daemon[16957]: [session uid=0 pid=16957] Activating via systemd: service name='org.gtk.vfs.Daemon' unit='gvfs-daemon.service' requested by ':1.1' (uid=0 pid=16956 comm="appstreamcli refresh-cache ")
>
> Do you think I should reassign this bug to the appstreamcli package?

I think this is an appstream bug, and I've reassigned it.

(Context for the appstream maintainer: Laurent found that various
gvfs services were unexpectedly running in root's `systemd --user`
session.)

I'm guessing this is caused by /etc/apt/apt.conf.d/50appstream having
this? Had you run 'apt update' in your root shell shortly before that
activation happened?

APT::Update::Post-Invoke-Success {
"if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi";

I think either appstreamcli's main(), or that apt configuration snippet,
should set the various magic environment variables to make GIO behave
less like a desktop and more like a system facility - I assume appstreamcli
doesn't actually need gvfs etc. to do its job! See also
<https://bugzilla.gnome.org/show_bug.cgi?id=767172>,
<https://bugzilla.gnome.org/show_bug.cgi?id=767183>.

This particular one would be solved by "GIO_USE_VFS=local", I think.

GIO_USE_VOLUME_MONITOR=unix and GSETTINGS_BACKEND=memory might also
be worth considering, although I suspect appstreamcli won't use
either of those in practice.

S

[Matthias Klumpp]

Hi!

> I think either appstreamcli's main(), or that apt configuration snippet,
> should set the various magic environment variables to make GIO behave
> less like a desktop and more like a system facility - I assume appstreamcli
> doesn't actually need gvfs etc. to do its job! See also
> <https://bugzilla.gnome.org/show_bug.cgi?id=767172>,
> <https://bugzilla.gnome.org/show_bug.cgi?id=767183>.
>
> This particular one would be solved by "GIO_USE_VFS=local", I think.

We had this workaround in both PackageKit and AppStream a while ago,
but we dropped it after the bug which triggered adding this workaround
was resolved:
https://bugzilla.gnome.org/show_bug.cgi?id=526454

But https://bugzilla.gnome.org/show_bug.cgi?id=767183 suggests this
misfeature is back :-(

I could re-add a workaround for this, but at this point any change
would need to be ACKed by the release team. So I would for no give a
low priority to this issue and let appstream in unstable migrate first
(and maybe see if there are other issues too to convince the release
team to update this).

I'm not very happy with this behavior of GIO - actually a reason not
to use it for system components. Although it also doesn't cause any
real problem here too...

Cheers,
Matthias

[Simon McVittie]

On Thu, 26 Jan 2017 at 20:46:16 +0100, Matthias Klumpp wrote:
> I could re-add a workaround for this, but at this point any change
> would need to be ACKed by the release team. So I would for no give a
> low priority to this issue and let appstream in unstable migrate first
> (and maybe see if there are other issues too to convince the release
> team to update this).

Sounds good. To be honest I don't think it would be difficult to
convince the RT to unblock a one-line fix for this - unnecessary daemons
running as root are fairly unambiguously not wanted, and the solution
is well-understood and easy to review.

S

[Laurent Bonnaud]

On 26/01/2017 20:12, Simon McVittie wrote:

> Had you run 'apt update' in your root shell shortly before that
> activation happened?

Yes I did.

Now with the workaround in place (masking the gvfs-daemon.service service) I see the following error message:

# apt-get update
[...]
(appstreamcli:11277): GVFS-WARNING **: Error creating proxy: Error calling StartServiceByName for org.gtk.vfs.Daemon: GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit gvfs-daemon.service is masked. (g-io-error-quark, 36)

Thanks a lot for the bug analysis!

--
Laurent.

[Simon McVittie]

On Thu, 26 Jan 2017 at 21:59:09 +0100, Laurent Bonnaud wrote:
> Now with the workaround in place (masking the gvfs-daemon.service service) I see the following error message:
>
> # apt-get update
> [...]
> (appstreamcli:11277): GVFS-WARNING **: Error creating proxy: Error calling StartServiceByName for org.gtk.vfs.Daemon: GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit gvfs-daemon.service is masked. (g-io-error-quark, 36)

That's as expected.

If you unmask the unit, and change the apt configuration snippet that I
mentioned in a previous mail to this bug so it runs
"if ...; then GIO_USE_VFS=local appstream-cli refresh-cache > /dev/null..."
then that should avoid the unwanted daemons without either producing
error messages, or preventing the use of gvfs if some other program you
run as root actually needs it.

S

[Laurent Bonnaud]

On 26/01/2017 22:51, Simon McVittie wrote:

> If you unmask the unit, and change the apt configuration snippet that I
> mentioned in a previous mail to this bug so it runs
> "if ...; then GIO_USE_VFS=local appstream-cli refresh-cache > /dev/null..."
> then that should avoid the unwanted daemons without either producing
> error messages, or preventing the use of gvfs if some other program you
> run as root actually needs it.

I confirm that the GIO_USE_VFS=local environment variable prevents the creation of the gvfs processes, even when the gvfs-daemon.service unit is unmasked.

Thanks again,

--
Laurent.