g-v-m vs. pamconsole mount option

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 06 January 2006 18:01, David Zeuthen wrote:
> On Mon, 2006-01-02 at 15:09 +0300, Andrey Borzenkov wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Mandriva defaulted to pamconsole mount option since switching to HAL.
> > Recently all removables started to be not accessible to logged in user.
> > The problem seems to be interaction between g-v-m and hal. Hal adds
> > /etc/fstab line containing pamconsole option; g-v-m now calls volume
> > Mount method with empty parameter set that basically results in calling
> > "mount /dev/node" - but on behalf of root, not user that has started
> > g-v-m, thus effectively making device accessible to root only.
>
> I've discussed this with the g-v-m and gnome-vfs maintainers and the
> thinking here is that g-v-m will invoke gnome-mount, see
>
>  http://lists.freedesktop.org/archives/hal/2005-December/004138.html
>

How is it going to help? It still calls HAL method and gets into the same 
problem. The problem is on HAL side not on client - gnome-mount does not do 
anything that differs from current gnome-volume-manager behavior.

May be I was not exactly clear, but once more:

- - user on console wants to mount device and of course access it. For pseudo 
filesystems like VFAT you need user= option to enable access _or_ make 
permissions 666 (probably not desirable) 
- - user calls HAL Mount method
- - HAL calls mount helper it has (likely hal-system-storage-mount)

what is lost in the meantime is user identification. HAL still has it via 
D-Bus; but at the time h-s-s-m is called it has no information about original 
user. Using fstab-sync+pamconsole and direct mount invocation on behalf of 
console user solves this by effectively appending user=<calling user> to 
mount options as /bin/mount value added service.

So HAL has to extract calling user and pass it on to the mount helper. Just 
how exactly it is to be done is subject do discussion - I believe it has to 
be stored as volume properties as long as device is mounted (just as extra 
mount option? In this case any program can fetch standard options via mount 
API). There is unfortunately race-condition here.

> I've discussed with Kevin Otte (KDE hacker) that KDE would use a similar
> scheme (albeit read settings from the KDE config system rather than
> gconf)
>
> > There seem to be more general issue - as far as I can tell, any user
> > logged in can call volume Mount or Unmount method - without any sort of
> > authentication and/or authorization performed.
>
> Only users at the console are, or should be, privileged to invoke
> Mount/Unmount - see hal.conf.in and the at_console policy  - hmm, it
> seems we need to add rules for the o.f.Hal.Device.Volume interface? I
> thought we had done that already. Kay?
>

It is there all right. This enables current g-v-m to call Mount method. And it 
also works. Unfortunately it also removes any write permissions from calling 
user :(

> The fstab-sync program will be removed in the next release; we just need
> to finish the Mount/Unmount methods, finish gnome-mount (a few days
> work, I hope to find some time soon) and do a security review before we
> can make a release.
>


Well, as the problem is not on client side, gnome-mount won't actually help 
much ... and removing fstab-sync effectively removes the only current way to 
do it right :(

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDvpGuR6LMutpd94wRAmZBAJ9t1ZfzI95dCMM1WmSLT3418aq8zgCeMIZ8
pZ1KxOpYvsc97BgXtbhLU9c=
=eq2y
-----END PGP SIGNATURE-----