12

UPDATE

Please correct me if I'm wrong: For working on my computer, with a GNU/Linux Distribution named Debian, I know two ways to enter a command, start an application, open a file, etc.:

  • a Command Line Interface where I enter text
  • a Graphical User Interface [a.k.a GUI]: an interface which provides "windows", symbols etc.

There is something going by the name "Window Manager". As I use GNU/Linux, I do work on the X-Window System [as far as I know].

enter image description here


Original Posting


Situation: I disabled automount in /etc/fstab for USB Sticks [e.g. /dev/sdb1]. Mounting requires to be root, or at least a sudo entry on the command line but not in a window manager (!). I do not mean automount, I mean "clicking on the symbol" in a window manager opens the device on the GUI without any questions, where on the CLI one must be root.

Question: How does mounting in a GUI work "under the hood"? Is there a configfile for window managers in general or does one have to set this individually?

I do understand and use mount command, I think to understand how to read and configure /etc/fstab and know where to look what the entries there and in /etc/mtabmean.

  • 1
    also, AFAIK window managers aren't responsible for this; the important thing is the (parts of the) desktop environment running underneath. e.g. I use Awesome GNOME - GNOME using Awesome instead of the GNOME Shell - and disks automount. but they wouldn't if I just used plain Awesome. honestly, I don't really understand your bounty - @slm's answer seems pretty clear. – strugee Nov 16 '13 at 23:35
  • 2
    In the very early days it was the automounter doing these tricks in the background (with pretty much the same mount-command you would use on the root-cli). Now there are own sub-processes that integrate with the GUI that do the job. See the answer from slm. – Nils Nov 18 '13 at 14:04
  • 5
    "I find it hard to believe that each and every one of [the various window managers] would have to look for their own way to solve this." -> It is never the window manager (WM) that does this. It's the desktop environment (DE). As for all of them having to do it themselves, well, they all do a whole lot of other things for themselves too. By choice. But they don't have to. GNOME, for example, has a GPL license, so any other GPL'd DE could just use GNOME parts, if they want to. – goldilocks Nov 20 '13 at 16:53
  • 2
    @goldilocks which e.g. Cinnamon and MATE did. – strugee Nov 20 '13 at 17:42
  • 2
    @strugee : GNOME is has a close historical relationship to GTK (which was originally for GIMP), and the lower level support libs (glib) that GNU also maintains and I believe proliferated out of GNOME and GTK. I'd guess almost everyone makes of glib, it provides a lot of stuff fundamental to a multi-tasking, event driven GUI "under the hood" (just: not the actual graphical parts). I think GNOME is fundamentally glib + gtk + a windom manager + some applications. – goldilocks Nov 20 '13 at 17:54
5

This is my understanding of the situation, but I'm not an expert so it is less technical than the other answers. This is what I understand after using these systems for many years, I have not studied them in any detail.

There are three main players here and between them they manage the mounts:

  • FUSE: This is at the center of everything, as described in its wikipedia page:

    Filesystem in Userspace (FUSE) is an operating system mechanism for Unix-like computer operating systems that lets non-privileged users create their own file systems without editing kernel code. This is achieved by running file system code in user space while the FUSE module provides only a "bridge" to the actual kernel interfaces.

    So, basically, this is what allows unprivileged users to mount filesystems.

  • gvfs : In the Gnome family of desktop environments (which includes Gnome, Mate, Cinnamon), this is (among other things) a daemon that will automatically mount newly connected drives. It does so via FUSE. I believe (but may well be wrong) the equivalent for the KDE family is called KIO

    The main processes of gvfs are (taken from man gvfs):

    • gvfsd - the main gvfs daemon
    • gvfs-fuse-daemon - mounts gvfs as a fuse filesystem
    • gvfsd-metadata - writes gvfs metadata
  • udev : This is a system that detects new devices and allows you to run scripts/commands when they are connected. For example, it is udev that detects a new screen and can mirror your desktop on it:

    udev is a device manager for the Linux kernel. Primarily, it manages device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware load.

    Specifically, gvfs seems to work through gvfs-udisks2-volume-monitor which is a udisks-based volume monitor. udisks itself however, relies on udev (see man 7 udisks).

So, basically (read "horrible simplification") what happens is that when you connect your drive, udev detects it and alerts the gvfs daemon which will then mount it as a FUSE device.

FUSE and udev will be the same for all desktop environments, what changes is the DE daemon that monitors udev and mounts the drive as a FUSE filesystem.

  • 1
    Put D-bus filling the gaps between udev, gvfs and everything else. – Braiam Nov 20 '13 at 19:29
  • You may want to update the information about gvfs. They are moving to GIO. – Braiam Dec 30 '18 at 16:03
8

It depends on your windowing environment (GNOME/KDE/etc.) but in GNOME, for example, you'll see daemons running called, gvfs-*-volume-monitor. These daemons are responsible for mounting devices when running the desktop environment, they have nothing to do with /etc/fstab, and operate completely independently.

As far as a config file, there are some files that are related to this that live in the user's home directory that is running the DE, $HOME/.local/share/gvfs-metadata.

This U&L Q&A titled: What is gvfs and why should I want it on my system?, attempts to explain what GVFS is. It does an OK job of explaining it. But I think what you're really asking about is addressed more by this U&L Q&A titled: Mounting USB disks automatically (How it works).

  • The answer seems to be in the HAL… I found some solutions for thunar [which I use] etc. The article pointed into a direction - thanks for that! - but I'm still looking for a common denominator… – erch Nov 14 '13 at 23:37
  • IIRC the DE doesn't need root because it uses FUSE (Filesystem in User Space). – strugee Nov 15 '13 at 16:23
  • @strugee guessing that DE means Desktop environment, I should look in FUSE. Do you have a hint, where? – erch Nov 18 '13 at 11:44
  • @chirp look up FUSE on Wikipedia: en.wikipedia.org/wiki/FUSE is it, IIRC. and slm has already answered. the answer is that the desktop environment, not the window manager, does automounting. – strugee Nov 20 '13 at 17:44
  • 2
    @chirp - See here: bbs.archlinux.org/viewtopic.php?id=95509. HAL has been deprecated, en.wikipedia.org/wiki/HAL_(software). UDEV is the replacement going forward: en.wikipedia.org/wiki/Udev – slm Nov 20 '13 at 18:31
8

The simple answer is they cheat. They don't use the fstab. They typically use a udev hook to catch insertion events, mount the disk manually as root, which may be passed to dbus to notify your file manager that you have a new disk or they might use suid utilities instead of dbus for unmounting. Unfortunately there are no standard configuration options for this, and since the desktop movement believes in hiding complexity they don't document this in the user documentation, only in the developer documentation, and they assume a single user system so USB drives only work for the first user to login to an X server.

  • YES! This is more what I am looking for. As newb, I'd like to ask where to start looking, erm: "Where do I begin" to trace this behavior [any hint would help me from getting sidetracked; a starting point or so would help hugely] – erch Nov 19 '13 at 18:10
  • 2
    @chirp to start exploring look at udev(7) and /etc/udev/rules.d/* – hildred Nov 19 '13 at 19:42
5
+150

PolicyKit (or Polkit) is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes.

It is a framework for centralizing the decision making process with respect to granting access to privileged operations (like calling the Mount() method) for unprivileged (desktop) applications.

An authentication agent is used to make the user of a session prove that the user of the session really is the user (by authenticating as the user) or an administrative user (by authenticating as an administrator).

GVFS is a virtual filesystem which allows mounting local and remote filesystems as a user along with trash support. There is also FUSE support that allows applications not using GIO to access the GVFS filesystems, but most DEs do authentication via Policykit for other things as well, like hibernating and shutting down the computer, and for the NetworkManager, so they don't need to use FUSE.

It consists of two parts:

  1. A shared library which is loaded by applications supporting GIO;
  2. GVFS itself, which contains a collection of daemons which communicate with each other and the GIO module over D-Bus.

The gvfs package needs to be installed, along with polkit-gnome for the polkit rules. Make sure that a graphical authentication agent installed and autostarted.

Configuration files for managing privileges must be different for each distribution. The Arch Wiki tells you to create a file under /usr/share/polkit-1/rules.d/. In Debian, they are located in /etc/polkit-1/.

Sources: Policykit on Debian || Polkit on Arch Wiki || GVFS on Arch Wiki || GVFS on GNOME Wiki!

  • Are you sure GIO stands for GObject Introspection? I would have thought it'd be called GOI if so. The Gnome people seem to call it GI. I haven't found another explanation of GIO's name but it does not seem to be the same as GI. – terdon Nov 24 '13 at 2:13
  • @terdon That was actually an edit by strugee (revision 10 on unix.stackexchange.com/posts/101951/revisions). Removing it... – Teresa e Junior Nov 24 '13 at 5:38
4

One common element you are looking for is FUSE, GNOME's gvfs, e.g., uses that under the hood.1 This is the interface with the kernel, and I believe it is common to all unprivileged (auto)mounting systems on linux [but see comments]. Individual DE's would not create their own version of this since that would require kernel patching.

That homepage link is in fact outdated, because as noted here, FUSE became part of the official kernel a few years ago, but it does describe the origins and purposes of the project (it is not just for unprivileged mounting).

The reason various systems may deviate in style beyond this is the same reason you have various desktop environments: they represent different visions of how/what the GUI should be. They're taking care of the form and function of the user interface, but FUSE does the actual mounting and kernel level stuff. Note that FUSE doesn't really do the "auto" part, it is more about the "unprivileged" part, but the auto part is pretty simple: all you have to do is poll, e.g., /dev. I've written a mounting application that works this way; it just watches for the appearance of new nodes.2 That part is maybe a hundred lines or so of C++. Easy-peasy -- no real need for a common API on that level.

1Or can, if it's doing a truly unprivileged mount. Teresa's answer may cover newer approaches to allowing accesses to normal mounts.

2As hildred observes , udev callbacks would be a better, less hack method.

  • I guess you meant "homepage" and I'll delete this comment after the typo disappeared ;) Great answer, as always, by the way! – erch Nov 20 '13 at 17:08
  • 1
    Since our answers seem to contradict each other, I did some tests. At least in Debian, without an active Polkit agent, the user can't mount. Also, the module fuse.ko isn't loaded even after I mount. (I'm using Thunar on Wheezy) – Teresa e Junior Nov 20 '13 at 17:20
  • 3
    @TeresaeJunior : Point (I've added a reference to here), although I don't think there's a contradiction since the polkit route is a bit of a userspace trick -- the mount is still a privilleged mount. The GVFS wikipedia page notes "GVFS may use FUSE" so I'll make that "may" instead of "does". – goldilocks Nov 20 '13 at 17:24
  • 1
    From the GNOME Wiki: "There is also fuse support that allows applications not using gio to access the gvfs filesystems." – Teresa e Junior Nov 20 '13 at 17:34
  • 1
    @TeresaeJunior : Yeah, so they are sort of concurrent, FUSE being a fallback. Of course, GNOME is not the only DE around, but I'm sure most of the others use glib (which includes gio) in various ways. TBH I've never liked automounting, so I don't have any anecdotes about it. Anyway, FUSE is a possiblity. – goldilocks Nov 20 '13 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.