Ok, sounds good. As an example of line 142 of xtrlock.c would be:
errno=0; pw= getpwuid_shadow(getuid()); if (!pw) { perror("password
entry for uid not found"); exit(1); }
Right?
It does mention later in the comments that:
/* logically, if we need to do the following then the same
applies to being installed setgid shadow. we do this first,
because of a bug in linux. --jdamery */ if (setgid(getgid())) {
perror("setgid"); exit(1); } /* we can be installed setuid root to
support shadow passwords, and we don't need root privileges any
longer. --marekm */ if (setuid(getuid())) { perror("setuid");
exit(1); }
So that would be only change right? Assuming that change right(Please
correct me if im wrong on ANY of this.)? Or would it still have to be
patched in?
Thank you,
Lewis I.
On Tue, Nov 9, 2021 at 3:00 AM Stuart Henderson <[email protected]> wrote:
> On 2021/11/08 23:37, Lewis ingraham wrote:
> > Hello thanks for the quick response! In what way do you think the code
> would have to be
> > changed? Can this be solved via a homemade patch or does it have to be
> an upstream patch?
>
> It could be patched locally.
>
> There are two possible ways to patch it.
>
> One would be a small change to use getpwuid_shadow instead of getpwuid,
> but this means installing it setgid _shadow i.e. giving it access to the
> entire crypted password database. This way it will only be able to
> handle local passwords, not login_ldap / login_oath / login_fingerprint
> / etc.
>
> The other way is preferable but harder to do. Use bsd-auth aka
> "BSD Authentication", which only requires setgid auth which has less
> access to the system (specifically it doesn't have direct access to
> the password database, only to a program which can test a supplied
> password). Also this could support other auth methods. This is described
> in the auth_open(3) manual. This would be preferable but harder.
>
>
