(In reply to comment #0)
> When starting a GNOME session without dk-disks running already, gvfs D-BUS
> activates dk-disks, which causes an automount attempt on internal hard disks.
> This doesn't happen if dk-disks is already running.

The desktop automounter actually should attempt to automount even if when devkit-disks is running. This is probably due to the GIO volume monitor implementation (gvfs-gdu-volume-monitor) incorrectly setting the flag for g_volume_should_automount() based on the :device-detection-time and :device-media-detection-time properties.

Worth looking into whether the bug is in GVfs (interpreting the values wrong), devkit-disks-daemon (setting the values wrong) or both...

As noted in comment 4, however, there should be no user interaction during automounting at startup. This means

 1. No "LUKS Unlock Volume" password dialogs etc.
 2. No error dialogs if an operation invoked during start-up triggers
    an error.
 3. No dialogs from PolicyKit

The first two are handled by Nautilus' automounter by respectively passing in NULL for the GMountOperation (meaning "no user interaction" requested) and also avoiding showing error dialogs for these operations. I believe this is working mostly fine.

The latter is more tricky to fix and the reason it is not fixed is that it's not apparent to me what the best way to fix it is. Basically, with the move to the new PolicyKit version all authentication dialogs happen out-of-band so to speak. For some background see the last half of this mail

http://lists.freedesktop.org/archives/polkit-devel/2009-May/000124.html

So, basically, right now devkit-disks-daemon will always pass in the POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION flag when checking authorizations. Meaning that any call to FilesystemMount() might trigger an authentication dialog. 

What happens on GNOME startup is that the desktop automounter attempts to mount all volumes. So if you have a system-internal volume the default configuration will require authentication to mount it. So you see the polkit authentication dialog at start-up. That's a bug.

There are two ways to fix this

 1. If GMountOperation is NULL (meaning no user interaction is requested)
    then the gdu volume monitor could pass a "no_auth_interaction" flag
    to the FilesystemMount() method on devkit-disks (and we'd honor that
    by not passing POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION
    to polkit.

 2. Since gdu-gvfs-volume-monitor is a separate process, it could call into
    the polkit authority to signal that requests from this process should
    never trigger authentication dialogs even if the mechanism (devkit-disks)
    passes POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION

I'm leaning more towards option 1. and also changing _all_ operations on devkit-disks to take an array of option strings (most of them do already, it's a great way to have some degree of extensibility) so you can always pass "no_auth_interaction" for any operation.

Thoughts?

FWIW, I've filed http://bugzilla.gnome.org/show_bug.cgi?id=587981 in the GNOME bugzila to track the GNOME side of this.

> This is quite a nasty usability issue on installed systems (since GNOME starts
> with a polkit auth dialog), 

Yep, the fact that we currently present an authentication dialog is a bug.

> and a potential data loss problem on the live
> system, since this auto-mounts all partitions without questions. This could
> potentially disrupt broken file systems, hibernated NTFS partitions, etc.

Oh, I don't think these are good reasons at all. By the same token all automounting / autoassembly is bad.

And if a file system driver corrupts your data, the solution is to fix the file system driver or fail the mount operation entirely (e.g. hibernated NTFS partition).

    David