Re: [Halevt-dev] Using halevt to replace ivman

[Adrian Mariano]

On Fri, Jul 03, 2009 at 05:02:13PM +0200, Patrice Dumas wrote:
> On Fri, Jul 03, 2009 at 09:58:52AM -0400, Adrian Mariano wrote:
> > 
> > I'm on Debian testing, and have installed the debian package version
> > of halevt.  I had to add an entry to /etc/PolicyKit/PolicyKit.conf to
> > enable mounting to work.  After doing this, I found that when I insert
> > a memory stick, it appears as /media/disk owned by root and with read only
> > permission (well, 775). 
> 
> Do you start halevt as a system-wide service, or as user?

I'm starting it as a system-wide service.  And it does run as the
halevt user.  

> > Subsequently typing "halevt-umount /media/disk" has no effect.  (No
> > error message, no effect.)  
> 
> If run as a system-wide service, it is normal that as a user, it has 
> no effect, and that there is no error message, since halevt-mount 
> didn't register the device as being handled as a user.

I'm not quite sure what your purpose is here, but having a command
issue no error message when you ask it to do something that it can't
do seems like a major design error.  It leads to major confusion when
the user is left wondering why the command didn't do anything.  People
don't type commands that aren't supposed to do anything.  

> > Running that command as root unmounts the
> > device.  Am I now requird to run "halevt-mount -s"?  
> 
> I don't think so. In general, when it is not run, it isn't really
> problematic, there can be stale entries in the .halevt-mount/......
> file but they won't be used anyway.
> 
> > A look in the halevt.xml config file reveals this 
> > 
> > <halevt:Device match="hal.block.device &amp; hal.block.is_volume = true 
> > &amp; (hal.volume.policy.should_mount = true | ((! 
> > hal.volume.policy.should_mount = false) &amp; 
> > (hal.block.storage_device.hal.storage.policy.should_mount = true | ((! 
> > hal.block.storage_device.hal.storage.policy.should_mount = false)  &amp; 
> > (hal.block.storage_device.hal.storage.hotpluggable = true | 
> > hal.block.storage_device.hal.storage.removable = true)))))">
> >    <halevt:Insertion exec="halevt-mount -u $hal.udi$ -o sync -m 002"/>
> > </halevt:Device>
> > 
> > 
> > It would appear that the mode is not chosen appropriately in this
> > default configuration.  "-m 000" would seem to be the correct choice.  
> 
> There is no choice that is correct for 100% of the cases. When I mount
> an ext2 filesystem from a removable device I expect the permissions to
> be preserved. It could be possible to make a special case for FAT/ext2,
> but then, I think that it becomes a bit too complicated for the default 
> case, and I also think that it is up to the distribution/user to make 
> the changes depending on the targeted use case.
> 
> It is certainly something that I took from ivman, since the comment
> still refered to pmount.
> 
> In CVS, an entity is used for mountable devices, it can help a 
> lot writing readable match.
> 
> > I also notice that the sync option is given.  From the mount man page:
> > 
> >        sync   All I/O to the file system should be done synchronously. In 
> > case
> >               of  media  with  limited number of write cycles (e.g. some 
> > flash
> >               drives) "sync" may cause life-cycle shortening.
> > 
> > I'd rather not have life cycle shortening of my flash devices.  Is
> > this really a good default?  
> 
> That's not an easy issue. I choosed to have the sync option as a default, 
> because mounting is done automatically and there is no UI to do the 
> unmount. So there is a severe risk of data corruption in case the mount is
> async and the removable device is removed. However the life-cycle 
> shortening, and also the performance would tend to mount async.
> 
> I have no definitive answer for that. I added a comment on that in the
> default conf file.
> 
> > A second observation is that if a device has an entry in the fstab
> > file then it appears to prevent that device from being mounted.  
> > 
> > With ivman, I had the following entry in my fstab file:
> > 
> > /dev/disk/by-id/usb-Sony_Card_R_W_-CF_50000007C7FA-0:0-part1  
> > /media/flashcard   msdos   rw,user,noauto,dmask=0000,fmask=0111 0 0
> > 
> > and ivman (well, pmount, I guess) would use this entry when it mounted
> > the device.  With halevt, the device does not get mounted at all,
> > anywhere (that I can find) when I insert it.  If I comment out this
> > entry, *then* the device gets mounted as /media/disk.  Why do I get
> > this behavior?
> 
> First of all you can use pmount instead of halevt-mount when mounting 
> devices. Maybe it is better than halevt-mount when doing system-wide 
> mounts.

Ok.  Since this did seem like the easiest solution I went this route.
And I think I also understand how it is that you can have copied the
umask from ivman and yet it doesn't work for me any more.  

The reason is that halevt-mount mounted the filesystem as "root root"
whereas pmount mounted it as "halevt plugdev".  I'm in the plugdev
group, so that means I can write to the filesystem when you use umask
002.  This may be a debian distribution issue.  I'm not sure.  

But if you mount as "root root" with umask 002 then it's impossible
for anybody but root to write, which seems just plain wrong.  It seems
reasonable that the umask should vary for different filesystems.  The
pmount man page, for example, lists different defaults for different
file systems.  For file systems that actually have permissions you
clearly want something different than for a fat file system.  

> As to why you get this behaviour, I have no idea. To debug that, you 
> could try to use directly halevt-mount on the command line, maybe 
> it will be more verbose, when invoked by halevt some information may be
> lost.

root# halevt-mount -u /org/freedesktop/Hal/devices/volume_uuid_3934_3939
Mount error for /org/freedesktop/Hal/devices/volume_uuid_3934_3939:
DBus Error org.freedesktop.Hal.Device.Volume.PermissionDenied: Device /dev/sdf1 
is listed in /etc/fstab. Refusing to mount.

Apparently this is intentionally chosen behavior.  If it sees the
device in /etc/fstab it refuses to mount.  I like the pmount behavior
better.

> Also, maybe it is because halevt is not run as root, but as another user
> (maybe the halevt user) and there is a permission issue?

Actually this could be an issue as well.  I ran the above as root.  I
can't seem to su to the halevt user (I guess because it is a no login
user), so I can't figure out how to run a command as that user.  But
it fails even as root as noted above.