On Wed, Aug 19, 2009 at 05:17:13PM +0200, Vladimir 'phcoder' Serbinenko wrote: > On Wed, Aug 19, 2009 at 5:08 PM, Robert Millan<r...@aybabtu.com> wrote: > > > > I agree with this proposal in general. Except with the concept of "users", > > which I think might be overkill. GRUB is not a Un*x with its /home and > > per-user settings. These passwords just protect resources, so I'm not sure > > if there's a point in managing users as an intermediate layer between > > passwords and the restricted resource. > The concept of users allows to use other authentication methods then > password. Consider a possibility of fingerprint authentications. 2 > users needing superuser privilegies can share the same password but > have trouble sharing fingerprints. Another possibility is LUKS > authentication - user is considered ok if his password unlocks the > slot number N. If we ask users to share the same keyslot on luks we > get in the way of luks keyphrase revocation. > Additionally this simplifies the configuration as you don't need to > write password at every menuentry directive. > While the concept of users isn't strictly necessary it allows easy > management of multiple authentication methods and is really helpful > even for just managing multiple passwords
Ok. Then it might be a good thing to have those in our current model, even if we don't support fingerprints yet. I'm fine with the proposed design. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
