Anton spotted a doas regression failure in t-run-keepenv-path after the
change to doas for LOGIN_SETALL. Since that test runs doas in a chroot
and the setup does not create a login.conf, login_getclass in
login_cap.c will return a login_cap_t with a NULL lc_cap (and errno set
to ENOENT) on L133. setuserenv returns -1 if lc->lc_cap is NULL causing
the "could not set user environment" failure.
As all the login_getcap* functions as well as gsetrl and setuserpath
succeed on a missing login.conf, the below path changes setuserenv to
return 0 as well. This matches what happens if the class has no setenv
capability right below. The comment is taken from gsetrl.
diff --git gen/login_cap.c gen/login_cap.c
index 67933653349..c142c0a7503 100644
--- gen/login_cap.c
+++ gen/login_cap.c
@@ -700,8 +700,11 @@ setuserpath(login_cap_t *lc, const struct passwd *pwd)
char *path = NULL, *opath = NULL, *op, *np;
int len, error;
+ /*
+ * If we have no capabilities then set _PATH_DEFPATH.
+ */
if (lc->lc_cap == NULL)
- goto setit; /* impossible */
+ goto setit;
if ((len = cgetustr(lc->lc_cap, "path", &opath)) <= 0)
goto setit;
@@ -753,8 +756,12 @@ setuserenv(login_cap_t *lc, const struct passwd *pwd)
char *beg, *end, *ep, *list, *value;
int len, error;
+ /*
+ * If we have no capabilities then there is nothing to do and
+ * we can just return success.
+ */
if (lc->lc_cap == NULL)
- return (-1); /* impossible */
+ return (0);
if ((len = cgetustr(lc->lc_cap, "setenv", &list)) <= 0)
return (0);
