Do not hardcode username in automount.conf

[probonopd]

I would like to enable automount with FM="..." in helloSystem as the default so that when a disk is inserted, a file manager window is opened.

But

• I do not want to hardcode a username in automount.conf. Hence, it would be great if we could find a way to open the file manager as the currently running user.
• The file manager must be launched with the user's environment variables

How can this be achieved?

Maybe something vaguely along the lines of

#!/bin/sh

# Executes a command as the user who runs the menubar process 

pid=$(pgrep menubar | head -n 1)
user=$(ps ho user $PID | tail -n 1)

# echo $pid

LINES=$(procstat -e $pid | tail -n +2 | tr ' ' '\n' | tail -n +5 | sed -r '/^\s*$/d')

for LINE in $LINES ; do
 export $LINE
done

sudo -E -u "${user}" "$@"

Do you know a more elegant way to achieve this? For example, via D-Bus?

[vermaden]

Hi,

I do not know DBUS so I can only modify automount ...

Check the __show_message() function. It has user detection based on the DISPLAY variable ...

Maybe that would help?

Regards.

[probonopd]

In my tests so far, just sudoing to the correct user alone did not have the desired effect, neither did my native attempt at restoring the environment variables.

I need to think more about it. For helloSystem most likely I could implement somehting in the launch command, but maybe you want a more general solution for automount.

[probonopd]

Thanks rodlie and zyga for this hint:

The process running as root (=automounter) sends a signal from the system service. User service or app (= file manager) subscribes to that signal. System service and user service are both on the system bus.

The File Manager D-Bus Interface would be a natural match, but the spec mentions nothing about there being a system and a user bus.

From Wikipedia it can be spectulated that every D-Bus Interface can be used over every bus, including the system bus?

GNU+Linux desktop environments take advantage of the D-Bus facilities by instantiating not one bus but many:

• a single system bus, available to all users and processes of the system, that provides access to system services (i.e. services provided by the operating system and also by any system daemons)
• a session bus for each user login session, that provides desktop services to user applications in the same desktop session, and allows the integration of the desktop session as a whole

I will see whether I can come up with a proof-of-concept based on this.

[probonopd]

Another use case:

FAT disk, can create new directory but not delete it in the file manager due to permissions issues.

• Permissions issues goes away if we use USER="user" in /usr/local/etc/automount.conf
• But we don't want to hardcode that variable for multi-user systems
• Can /usr/local/etc/automount.conf be changed to use USER=$USER instead, with $USER being dynamically resolved?

[vermaden]

Do you plan to use more then one use at once on helloSystem?

[probonopd]

Do you plan to use more then one use at once on helloSystem?

Not at the same time, but one after another. Like in a family or university lab where the same machine is shared by multiple persons.

[grahamperrin]

Like in a family or university lab

Per-user home directories, where helloSystem is installed (not live boot), yes?

This is implicit in the opening post "… currently running user. …" but I'd like to check.

where the same machine is shared by multiple persons.

I should expect concurrent logins (with user switching, or words to that effect).

[probonopd]

I should expect concurrent logins (with user switching, or words to that effect).

Need to check how the Mac handles FAT32 disks in those situations. I would say, FAT32 does not have the concept of per-user filesystem permissions, and hence a FAT32 disk should be fully available to all users on the system. Hence I am currently using mode 777... especially as long as automount can't figure out (yet?) which user has caused the mount operation.

https://github.com/helloSystem/ISO/blob/a5f6de0bb262fbf93327950d71c443530a445c82/settings/script.hello#L331-L338

[ldo]

A D-Bus session bus is associated with a GUI session. Since a file manager is a GUI app, it only makes sense for it to communicate via a session bus.

[probonopd]

Can root communicate with the session bus?

[ldo]

There can be more than one.

[probonopd]

@ldo: How can root communicate over D-Bus with all non-root applications? Use case: automount (running as root) needs to inform the file manager (not running as root) about certain events.

[ldo]

Not sure what the right answer is here. Each currently-logged-in user will have their own session bus. Which one should open the file manager? Maybe the answer is for the relevant GUI session to listen for relevant device-mounted signals on the system bus, and only that one will respond by activating its own file manager instance.

Edit: well, actually, there’s no harm in all logged-in GUI sessions listening for volume-mount events. I guess there is the issue of who gets ownership of things like VFat volumes that have no innate file protections, but that’s a separate problem. ;)

[probonopd]

After thinking about it some more, I think I can do without this by implementing the logic to open a window whenever a new disk becomes available in the file manager itself.

For my use case this works because I have control over the file manager source code but it would not work if you want it to work with random file managers. I'll leave it up to @vermaden whether this ticket ("Do not hardcode username in automount.conf) should be kept open.

[probonopd]

Seems like the answer is in

https://hauweele.net/~gawen/blog/?p=834

at the very bottom, combined with my initial post.

[vermaden]

The DBUS code in that blog also requires USER ...