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

[Patrice Dumas]

On Fri, Jul 03, 2009 at 06:06:56PM -0400, Adrian Mariano wrote:
> 
> 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.  

Indeed, it would be better to have an informative message. I uncommented
and enhanced the error message that was previously commented out.

> > 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.  

That's strange. I guess that halevt itself runs as "halevt plugdev"
so that when invoking halevt-mount it should also be invoked as
"halevt plugdev".

> 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.  

I disagree. It may be wrong sometime, but not always. You are trading
security for convenience. Of course with usb sticks and with FAT, 
security is very low anyway, but restrictive umask could be of interest.

> It seems
> reasonable that the umask should vary for different filesystems.  The

Agreed.

> 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.  

Looking at the pmount man page, they propose very restrictive umasks
in the default case. In any case I'd be willing to accept patches for 
halevt.xml to use a different umask for different filesystem types (for 
the CVS halevt.xml file, and in any case it would be much easier with
the entity), that I could integrate within comments or directly in 
halevt.xml.

> > 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.

It is a 'feature', sort of. It is not halevt-mount that is responsible
for that, but halevt-mount mounts through HAL, and it is HAL that has
this 'feature'. pmount is different, it is suid root and doesn't mount
through HAL (though it may use hal to get filesystem informations).

> > 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.  

I don't know either. I can see how a 20 line C program could do that, but
I don't know a command that do. su and sudo execute a shell, while what
is needed would be a plain (setuid, getuid, execv).

--
Pat