Re: [hackers] [slock] Unify how we check passwords between different OSes

From: Quentin Rameau <quinq_AT_fifth.space>
Date: Wed, 7 Sep 2016 12:42:20 +0200

> > > > diff --git a/slock.c b/slock.c
> > > > …
> > > > +#else
> > > > + if (rval[0] == '*' && rval[1] == '\0') {
> > > > +#ifdef __OpenBSD__
> > > > + if (!(pw = getpwnam_shadow(getenv("USER"))))
> > > > + die("cannot retrieve shadow entry (make sure to suid or sgid slock)\n");
> > > > + rval = pw->pw_passwd;
> > > > +#else
> > > > + die("cannot retrieve shadow entry (make sure to suid or sgid slock)\n");
> > > > +#endif /* __OpenBSD__ */
> > > > + }
> > > > +#endif /* HAVE_SHADOW_H */
> > >
> > > We should probably use another error message in the not __OpenBSD__ case,
> > > maybe something like "slock: unknown shadow passwd system\n". Also please
> > > add the "slock: " prefix to the other die() call.
> > The second message is right here: if we got a pw->pw_passwd being "*", it
> > means that we didn't have access to the shadow password in the first pass,
> > which is how it works on other systems (those being the one stated in the
> > previous mail).
>
> I see that obviously only one of those die() calls will be compiled into the
> binary, but keeping error messages unique helps finding the actual place where
> it was called. In this case having different messages would mean we don't have
> to ask someone reporting this error to us if he had __OpenBSD__ defined or not
> during the build.
>
> I'd even go as far as adding "Keep error messages unique" to the style guide.
That's a bit ambiguous because as you stated the error message is unique
in the resulting program, only duplicated in the source (that's what we
get for using #def guards :p)
But I understand what you mean, so what do you think about prefixing
them with the actual function name (and prepending the tool name too of
course):
die("slock: getspnam: cannot retrieve shadow entry[…]");
die("slock: getpwnam_shadow: cannot retrieve shadow entry[…]");
die("slock: getpwuid: cannot retrieve shadow entry[…]");
?
Received on Wed Sep 07 2016 - 12:42:20 CEST