[Jonas Smedegaard] > Let me try rephrase: Why use a mechanism more complex than e.g. sudo to > govern crossing boundaries of access rights?
Because I believe it is a good idea to be able to authenticate into ones own freedombox without having to send the password over the net (even encrypted). The scenario I have in mind is a linux, windows or mac box hooked up to ones own Kerberos/AD domain, which can log into freedombox using Kerberos, and which can get a Kerberos ticket also when away from home. > If Kerberos is used only to issue tickets automatically based on > user-id, then I see no benefit of that mechanism. I agree. > If Kerberos is used also for authenticating human users of > FreedomBox, how do you then imagine making that dead user-friendly? For this to work, I believe the Freedombox had to become a AD domain controller, thus allowing any windows machine to "join the domain" of the Freedombox and the browser to log into plinth using the Kerberos ticket. But after looking at plinth/exmachina a bit more, I believe the best way forward right now is to drop exmachina completely and rewrite plinth to use sudo. Instead of talking to exmachina, it should call 'sudo /some/privileged/helper/script' we write to handle the operations plinth need, and ask it to do the privileged operations. This would allow us to get something working very quickly. For package installation, I suspect aptdaemon is a good way to get everything we need (including debconf interactions), using the dbus. Any objections to dropping exmachina? I suspect 200 lines of python and 3-4 hours should be enough to do the rewrite. -- Happy hacking Petter Reinholdtsen _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
