TEAM MEMBERS WANTED!
If you think that the project is interesting and has potential to make Linux easier for use, if you are familiar with C or you want to learn C on a real project, if you have ideas for enhancements, do not hesitate and contact me at rozelak at volny dot cz

More information will be added in near future ...

New way of mounting

Mounting of removable devices, such us USB discs, CD/DVDs, cameras, and others, requires usually some manual work, and sometimes even root access (modifying /etc/fstab) and/or kind of advanced experience (manipulating with udev). The fact, however, is that ordinary users prefere just plugging a device into their computer (usb discs, cameras, ...), or entering a mountpoint directory (e.g. /mnt/floppy) and expect the data be prepared for work. They do not want to login as root and/or change configuration every time a new usb borrowed from colleague is plugged in, especially not in cases when they need everything "just working" on their computers. Moreover, there are also some users who prefere the work in linux, but actually do not know how to configure anything (I personally know some of them) - they just have configured linux on their computer, not even knowing root password.

MountManager (referred also as MM), therefore, aims to hide the work connected with mounting, still allowing users to define their consistent working environment - the same devices always mounted to the same mountpoints. In a top of that, the manager ensures the privacy of users data - they are encrypted/decrypted if required, using user-provided information, and they are not allowed to be accessible by other users logged into the same computer. Some window managers, such as KDE or Gnome, try to handle mounting in their (specific) way, but MountManager aims to offer cross environment and cross distribution solution more reach in features, exactly as [NetworkManager] does it for network configuration. The advantage of being independent is that once a new feature added, all window managers and/or distributions can benefit from it in short time.

Similarly to [NetworkManager], MountManager also consists of one system daemon which carries out all the mount-related work, and GUI client running under window manager (e.g. docked in the systray panel). Those two parts communicate through system dbus, daemon informing client about success/failures of both automatic and user-requested mounts/umounts (based on information provided by the client) and client handles user-defined configuration and informs the daemon where the user requires to mount this and that.

All the following texts are also considered to be points for discussion. If you think that something is completely wrong or if it could be significantly enhanced, if a new original function should be added or even the whole idea could be much improved, do not hesitate and write your suggestions to the devel mailing list.

The main properties of MountManager can be summarised

simplicity:

the work with MM (or rather with client connected to MM) should be as simple as possible. Users should not set anything complicated, if not necessary - in the majority of cases users should just choose mountpoint, device (or its unique ID) and set password, if data encrypted

consistency:

once a device mount set, the device must always be mounted according to the configuration. However, the change of configuration must, naturally, be possible

automation:

mounting should be as automatic as possible, everything that can be done automatically or detected automatically, should be; users must not require root account for any kind of mounting (when not disabled by root). On the other hand, user should still be able to mount devices through simple GUI, as well as umount/eject those already mounted by one or two clicks (see simplicity)

universality:

all types of local and network filesystems must be handled by MM, all must behave as similar as possible from the user's point of view

keep informed:

all important changes (new device mounted/umounted/unplugged, etc.) should be presented to user in simple and understable way. Especially in cases when mounpoint is determined by MM, user must be informed where to look for the data

safety:

MM must ensure that data cannot be accessible by other users (excluding root, naturally, as in the case of classic mount)

How MountManager is planned to work

• once MM is started, it checks system and makes a note about devices already mounted, as well as about for which users they are mounted
• it also checks which devices are plugged in, and mounts them (determining the mounpoint and access as described here) if configured to do it; otherwise it just makes a note about the devices presence.
• once a client is started, it should send user-defined configuration to the MM. MM then, according to the configuration received, remounts and modifies access for the devices already mounted, and/or mounts those plugged but not mounted yet. From this point, the data on the devices must be accessible by the user through the mountpoint defined by him/her
• the client can also send which mounpoints are required to be monitored, and what is expected to be mounted once a mounpoint is entered
• MM continues with device monitoring, and mounts the new plugged devices according to the user-defined configuration (if there is such for a device just plugged), or determines the mounpoint and access as described here. The information about new device mounted is sent to the client, as well as information about a device is being unplugged
• MM also monitors if a monitored mountpoint was entered/leaved, and mounts/umounts it according to the configuration if so. Again, information is sent to the client
• when user changes existing configuration, creates new one, or just required to umount/eject a device, MM adjusts the existing mounts according to the requirements
• once the client disconnects (window manager is shut down correctly), MM starts umounting all the devices mounted for the user
• once a defined signal is received, MM umounts all the remaining devices mounted by MM and exits

How MountManager determines the mounpoint

• when a new device is plugged in, MM is notified about it through HAL,
• the node of plugged device (/dev/XXX provided by HAL) is searched in /etc/fstab file. If found, but without user or users option defined, the device is mounted according to the fstab record, accessible by root only,
• if the device has user/users option defined in /etc/fstab, the unique device UID (provided by HAL) is searched in the list of user-defined devices configuration (including system-wide configuration of MM which is preferred)
  • if found, device is mounted according to the configuration, including possible decryption and so on. It actually overrides mountpoint in /etc/fstab, if there is such (necessary e.g. when several USB storage devices are plugged at the same time),
  • if there is no user-defined configuration for the device, the mountpoint defined in /etc/fstab is used (user or users option exists in this case in /etc/fstab, so device is mounted to be accessible by users as well)
• if there is no /etc/fstab entry
  • and there is user/users request how to mount the device, MM mounts the device according to that request,
  • if there is no user/users request how to mount the device, MM uses the information provided by HAL to generate the name of mounpoint accessible by all users from a given group (e.g. plugdev).

Similar projects:

ivman - a generic handler for HAL events.
gnome-mount hal/dbus-based mounter tied to GNOME