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.

strugee
  • 14,951
erch
  • 5,030
  • protip: IIRC /etc/mtab isn't recommended anymore; use /proc/mounts instead – strugee Nov 15 '13 at 16:19
  • 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
  • 1
    your statement of "there are about 20 different window managers" is not relevant, as again, it isn't the window manager doing this. it's the desktop environment, and there are only ~4 DE "families" (grouping e.g. Cinnamon and GNOME 3 together, since they share an ancestry). as a side note, there are much, much more than 20 window managers. – strugee Nov 16 '13 at 23:36
  • Could you please explain a bit more in detail what you mean? Or at least sum up your comments in one, plz? – erch Nov 17 '13 at 00:35
  • I'm not entirely sure what else I can do to clarify, besides making sure you know the difference between a DE and a WM. we can chat, if you like; I'm almost home and in front of an actual keyboard. or if there's something specific I can clarify, I'd be glad to do so. – strugee Nov 17 '13 at 01:04
  • @strugee a hint about "where to look" would help Also: "protip: IIRC /etc/mtab isn't recommended anymore; use /proc/mounts instead" - where did you read this?! – erch Nov 18 '13 at 11:38
  • 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
  • 1
    @chirp "where to look" for what? desktop environments? window managers? look them up on Wikipedia. or: http://unix.stackexchange.com/questions/13475/difference-between-a-window-manager-and-a-desktop-environment – strugee Nov 18 '13 at 16:24
  • 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
  • @goldilocks yep. that's not all of it, of course, as there are quite a few parts of the platform (e.g. GSettings) which aren't part of those. but that does compose the majority of the desktop stack. – strugee Nov 21 '13 at 20:45

5 Answers5

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).

Community
  • 1
slm
  • 369,824
  • 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
  • @chirp HAL is dead... long live HAL. – Braiam Nov 20 '13 at 18:06
  • @Braiam yes-ish: Is there an article or so that explains this? Or is this another thingee on the level of "Intel vs. AMD"? I'm not that deep into this topic, though willing to dig deeper… – erch Nov 20 '13 at 18:20
  • 2
    @chirp - See here: https://bbs.archlinux.org/viewtopic.php?id=95509. HAL has been deprecated, http://en.wikipedia.org/wiki/HAL_(software). UDEV is the replacement going forward: http://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.

erch
  • 5,030
hildred
  • 5,829
  • 3
  • 31
  • 43
  • 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

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!

admirabilis
  • 4,712
  • 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 02:13
  • @terdon That was actually an edit by strugee (revision 10 on http://unix.stackexchange.com/posts/101951/revisions). Removing it... – admirabilis Nov 24 '13 at 05:38
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.

terdon
  • 242,166
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.

goldilocks
  • 87,661
  • 30
  • 204
  • 262
  • 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
  • @chirp Feel free to leave any comment that includes "Great answer, as always" -- Thanks! – goldilocks Nov 20 '13 at 17:10
  • 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) – admirabilis 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." – admirabilis 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
  • @goldilocks fuse and automounting are completely seperate ideas, although fuse may be automounted it is not part of automounting. also I think you are confusing fuse with vfs. fuse is a real filesystem mounted by the kernel that is implemented in user space programs. vfs is a virtual filesystem implemented in a library that may or may not use the kernel for file operations, depending on which path is being opened. – hildred Nov 20 '13 at 21:55
  • @hildred No, I'm pretty clear about FUSE not being what does the automounting -- that's stated explicitly several times. FUSE makes it possible to have unprivileged mounts of attached devices, which is why it is part of the "how" in "How does mounting on the GUI work under the hood?" – goldilocks Nov 21 '13 at 14:46
  • Okay, I put the first "auto" in brackets to make this clearer. Still, if you make it through the third paragraph, I think it is really, really clear what was meant, since this is partially a discussion of the relevance of the "auto" part. Note you can have GUI mounting tools that that are for manual mounting by an unprivileged user (no auto involved -- and there's no auto in the question, either). These will still use udev or some equivalent method to detect newly attached devices. ;) – goldilocks Nov 21 '13 at 15:28