On Thu, 2006-01-12 at 18:38 -0800, Artem Kachitchkine wrote: > > Maybe I just fail to see the point.. but all that HAL does in this > > respect is to provide privileged operations to users that are not > > usually privileged. I think we do this in a secure way (do you > > disagree?) > > Well, you know what they say about ciphers: breach is rarely in > alrogithm, it's most often in the implementation. People have written > unix root daemons for years and have come to a conclusion that it's not > a good idea unless there is no way around. Withing limits, of course, > it's all about balance, you gain something, you lose something. > > Writing root code requires more discipline, more peer review, more > auditing, more testing... It's like walking around with a loaded gun: > sure it's safe if you are a responsible person, but guess who's most > paranoid about that - that's right, folks who actually used firearms a lot.
Well, I definitely subscribe to this line of thought. Well put, btw. Actually, to put a thought forward, I think that with the framework we got today, adding the privilege of e.g. invoking the method Foo() for an unprivileged user is very easy [1] in so far that you get a lot of the auth checking for free. This code (both in D-BUS and HAL) of course needs to be very carefully reviewed (like any other code) but it's the same code running for all methods. Hence, eventually we'll get it right, just like other pieces of code :-). However, there's no such thing as a free lunch so the actual binary or script performing the method needs to do careful checking and/or drop privileges. I'd still argue it's less code/work than with e.g. a setuid approach and hence we should see less buggy / dangerous code. Also, I do think it's a bit more slick, intuitive even, to provide functionality this way in so far that you'll get the whole association between the hal device object representing the hardware and the actual method. Contrast this with e.g. a setuid mount helper; here you need to figure out the device file and pass that. Also, all the D-BUS goodness such as introspection (though we need that in HAL still), language bindings etc. comes to mind... though this is a bad example for Mount() et. al. since we wrap it in gnome-mount for other reasons (settings in gconf) :-) Finally.. sometimes you really need those extra privileges.. for example, for the Mount() method we also create/destroy directory entries in /media. Walking the line between providing security and providing functionality to the user is indeed a fine one. [snip] > In addition to the above, users will have more choice with respect to > automounters, they are not restricted to HAL. For instance, some control > frea... uh, experienced users, don't like automatic mounters and prefer > the standard /sbin/mount. Using mount privileges, Solaris doesn't need > suid-root /sbin/mount commmand nor any special fstab options - it just > works. Lowering the bar from HAL methods to the system call level makes > the system simpler and more flexible at the same time. Well, some users of Linux based system are equally, heh, "experienced", and they just turn off auto-mounting in g-v-m and do their perverse thing in the terminal. More power to them. So, basically, I don't see why you should disable Mount() et. al. in HAL just for this reason. Cheers, David [1] : just add an fdi file like this http://cvs.freedesktop.org/*checkout*/hal/hal/fdi/policy/10osvendor/20-storage-methods.fdi and define your policy in e.g. http://cvs.freedesktop.org/*checkout*/hal/hal/hal.conf.in or another D-BUS configuration file. _______________________________________________ utopia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/utopia-list
