Hi David! David Zeuthen [2005-05-12 14:15 -0400]: > I wonder if you saw this > > http://lists.freedesktop.org/archives/hal/2005-February/002163.html Yes, I saw that and I think this is a good idea. Right now I have a better feeling because 100% of hal is running as normal user, but if the root part of hal is tiny, then this would be a good compromise. > Uhm, no, what this is about is to make hal offer the 'do-this-thing-to- > what-this-device-object-represents' in a convenient way. The policy is > still in the caller invoking the method. > > Please don't confuse this with hal starting to enforce policy because > this is just not the case. Okay, agreed. So essentially luks-setup would be a similar "setuid" (well not really) root wrapper around cryptsetup as I recently did in pmount. Is that right? > > OTOH we already have pmount which does the root part, so it is > > straightforward to put the cryptsetup integration into pmount. In > > addition, luks-setup does not yet exist in hal 0.5.1. > > No one sent the patches yet, no. hal does not need any patches for pmount, g-v-m does. But given the fact that g-v-m upstream never bothered to apply any bug fixes and improvements, I stopped to submit g-v-m patches upstream. E. g. Sjoerd wrote a very nice patch to select mount programs and arguments with configure options, but it is a PITA to drag such huge patches through many new upstream versions, so I eventually dropped it and replaced it with a crude hardcoded, but small hack again. It is tiresome to have a debian/patches directory that is bigger than the upstream source itself, but that's life I guess. (In the long run I guess g-v-m has just to be replaced by something sanely written DE agnostic backend and a thin gnome frontend, so that the KDE and other guys can easily adopt it to their favourite DE). On the other hand, g-v-m is probably the single app that distributions will actually want to customize (that's why it should be rewritten in a more modular way). > I'd rather, in the grand scheme of things, have that distro X didn't > have to do A while distro Y did B. Right, that would be ideal. The basic building blocks should be the same (like udev, hotplug, hal). However, I don't really see a big problem if one distro uses pmount, and another one uses fstab-sync. Maybe these distros have good reasons for fstab-sync, and it may be as hard to convince them about pmount as it is for Ubuntu to convert to fstab-sync. But as long as hal and this backend is only connected through g-v-m, where it can be easily exchanged, I don't really see a big problem with it. If hal eventually supports cryptsetup integration, then of course I'd be happy to adopt this in Ubuntu, too. In Debian, there are a lot of command line users, and users who don't use KDE/Gnome, so cryptsetup in pmount has benefits regardless of luks-setup. > I've also mentioned it would be nice to deprecate fstab-sync and use > something like pmount instead but I've not seen any patches to do > so. Instead I see Ubuntu going off in their own direction. Sigh. Why, so far you adopted all patches that Debian or Ubuntu made to hal, as long as they make sense for upstream. Thanks to that we are down to three hal patches in Ubuntu, one was already mailed to you (increase maximum number of connections), the other ones are Ubuntu specific (mount policy); none of the patches change hal's general behaviour. pmount is available upstream and in Debian, everybody is free to use it. If you need anything else, I'd be glad to submit it here. :-) Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developer http://www.debian.org
Attachment:
signature.asc
Description: Digital signature