Le ven. 26 janv. 2024, 23:15, Daniel Kiper <dki...@net-space.pl> a écrit :
> On Fri, Jan 26, 2024 at 02:12:31AM +0300, Vladimir 'phcoder' Serbinenko > wrote: > > Please detail your use case. GRUB already had user framework in the same > > problem space. > > I am not sure what exactly you mean by "user framework". Could you > elaborate or point us code examples? > https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-authorisation > > Anyway, we need a mechanism to disallow access to CLI, arguments editing > for kernels, etc. I.e. user cannot change widely understood boot config > even being at the console. > Yes and it's exactly what happens as soon as superuser is set. Basically this patch is equivalent to having a superuser without a valid password. AFAIR it's achieved by setting superuser's but not issuing password commands. If not we can have password_deny command. > > Daniel > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
