Thoughts about HAL, Ivman and Pmount.

Jonatan Liljedahl lijon at kymatica.com
Thu Oct 27 08:02:43 PDT 2005


On Wed, 26 Oct 2005 17:04:30 -0700
Artem Kachitchkine <Artem.Kachitchkin at Sun.COM> wrote:

> > since if two users are running ivman at the same time there will
> > be big trouble when both tries to mount the same thing under /media.
> > There will be a war about who owns the mountpoint.
> 
> I think a device ownership policy should assign ownership for each 
> device to users or groups of users. Such a policy should be external
> to HAL and volume managers.

How do you mean external? But if automounting is done on system level
(not user session), for example by ivman running as ivman.plugdev,
shouldn't ivman set the correct ownership (like "ivman.plugdev" and then
let all users who should be able to access and unmount media be part of
the "plugdev" group)

> A trivial example of such policy is:
> whoever owns console also owns removable media. Obviously, this policy
> is not particularly multiuser-friendly (mufy), although it probably
> works okay in the special case of fast user switching.

It doesn't work if all users log into the box trough X terminals. (the
console isn't used by any user)

> This should be
> fixed by a mufy ownership policy and a mufy volume manager. I'm
> working on a HAL extension to make this easier to implement, but
> that's just one piece of the puzzle.

Sounds interesting, would you like to tell more about this?

> > Therefore I have made a patch for pmount that lets any user who's in
> > the same group as specified by the gid= mount option unmount a
> > device: http://kymatica.com/stuff/pmount-0.9.3-lijon.patch
> 
> IMHO hardcoding this into pmount is not the way to go. At the very 
> least, this should be configurable.

The thing is, pumount already checks if the uid= mount option matches,
but if it doesn't (uid=ivman,gid=plugdev and user is john doe) then
pumount says "device was not mounted by you". But all in "plugdev" group
already has rw access inside the mountpoint so why shouldn't they be
allowed to unmount it? And how could they possibly unmount the device if
it was mounted by someone else (ivman)?

(imho, automounting should not be done by ivman's runned by users, since
it's not very mufy)

But sure, it could be configurable.

> > The syntax of ivmans config files is kind of limited in
> > many ways, while .fdi files seems to be very flexible.
> 
> It's kind of a stretch to compare these two. HAL is a system-wide 
> service with system-wide settings. Volume managers such as g-v-m and 
> ivman are user applications with per-user settings.

But ivman has double functions, it's also used as a system service with
system settings.
(It's then running as ivman.plugdev and using /etc/ivman/*.xml config
files)

The problem with ivman compared to HAL is the limited config files, for
example there's no way to pass mount options, the only thing you can say
is mount = true or false. Another problem is that the system-wide ivman
waits 5 seconds before automounting stuff, which means that user-ivmans
won't have $hal.volume.mount_point$ available when they trigger on a
device insertion. My thought was that since I think automounting should
be done by system, not user, I could as well let HAL do it instead of
ivman. But maybe I should get a better volume manager instead?

> It goes back to
> the old discussion that storage.policy should be moved out of HAL.
> David, do you still think it's a good idea? I think it's the right
> thing to do.
> 
> > How would I set up hald to do the automounting
> 
> HAL is not supposed to mount volumes. I for one would be disappointed
> if it does.

I see.

> Overall, it's not quite clear what is the exact problem you're trying
> to solve.

I don't have an exact problem, I'm just trying to figure out what's the
"right thing"... =)
How should it all be set up? Automount or not? If so, by what and how?
fstab-sync or not? Permissions and ownership? How to handle multi-users?
etc...

/Jonatan    -=( http://kymatica.com )=-


More information about the hal mailing list