On Thu, Jan 12, 2006 at 11:03:45AM -0500, David Zeuthen wrote: > On Thu, 2006-01-12 at 16:18 +0100, Kay Sievers wrote: > > > But today all privileged access to a device happens in a helper called > > > out from hald, no? That's in hald/linux2/probing and elsewhere. > > > > Yes, most of it. Who will start add-ons that need privileges? > > The helper process of hald running will be running as uid 0.
So, what will spawn a addon for a new detected device, if the main daemon does not have the needed privileges? > > > There may be a few cases (reading battery info comes to mind) where we > > > need to clean this up too; that's all part of the work of separating > > > hald into two processes - the unprivileged one handling D-BUS requests > > > and the uid 0 one that executes helpers. Don't you think this is nicer, > > > we get less code running at uid 0 which is always good even if there are > > > no real threats (still I'm waiting for Martin to point those out). > > > > Sure, it's nicer, I never disagreed, but I didn't see a convincing > > proposal that still works as expected. If we are going to do that than > > we should reconsider my old proposal, to make the hal device store > > generic and not part of the device handling. You didn't like the ipc > > overhead that time, which is what this privilege split model will > > introduce anyway. > > Well we can still do that at some point if you convince me it's a good > idea ;-) It's still valid, sure. If we go doing all ipc, that sounds obvouis to me to do it. > > I'm still can't really imagine, what will be left to the "unpriv. > > main daemon" if we put everything into external privileged processes. > > Then we can just rip out the store and make it generic for other > > subsytems too, to put in their objects too and use all the nice > > infrastructure like fdi files, callouts, ... > > Along the way that might be nice. But one task left for the unprivileged > daemon is also reading sysfs stuff. Yeah, you can spawn a setuid binary for every file to read. :) Kay _______________________________________________ utopia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/utopia-list
