Bug 37416
| Summary: | [PATCH] sshd doesn't set the root login class properly | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Tony Finch <dot> |
| Component: | bin | Assignee: | Tony Finch <fanf> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.5-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->patched This has already been fixed in rev 1.19 in current. This is a MFC remined. Responsible Changed From-To: freebsd-bugs->green Over to green who made the commit to current. State Changed From-To: patched->closed MFCed, thanks! State Changed From-To: closed->open This bug has returned with the introduction of openssh-3.4p1. Responsible Changed From-To: green->fanf I'm investigating this one. This re-fixes the login class handling in recent versions of sshd.
Shall I commit?
--- auth.c 3 Jul 2002 22:11:41 -0000 1.3.2.5
+++ auth.c 26 Jul 2002 21:52:05 -0000
@@ -24,6 +24,7 @@
#include "includes.h"
RCSID("$OpenBSD: auth.c,v 1.43 2002/05/17 14:27:55 millert Exp $");
+RCSID("$FreeBSD$");
#ifdef HAVE_LOGIN_H
#include <login.h>
@@ -479,7 +480,7 @@
if (pw == NULL || !allowed_user(pw))
return (NULL);
#ifdef HAVE_LOGIN_CAP
- if ((lc = login_getclass(pw->pw_class)) == NULL) {
+ if ((lc = login_getpwclass(pw)) == NULL) {
debug("unable to get login class: %s", user);
return (NULL);
}
Tony.
--
f.a.n.finch <dot@dotat.at> http://dotat.at/
WEST FORTIES CROMARTY FORTH TYNE DOGGER: VARIABLE BECOMING SOUTHERLY 3 OR 4,
OCCASIONALLY 5 LATER. FAIR. GOOD BECOMING MODERATE OR POOR.
Tony Finch <fanf@FreeBSD.org> writes: > This re-fixes the login class handling in recent versions of sshd. > Shall I commit? Yeah, thanks. DES -- Dag-Erling Smorgrav - des@ofug.org State Changed From-To: open->patched Fix committed to -CURRENT State Changed From-To: patched->closed Fix MFCed. |
sshd uses the "default" login class for users with uid=0 instead of the "root" login class when setting up the user's session. Fix: It isn't clear to me whether the bug is entirely in sshd or whether some of the problem lies in libutil. Only login_getpwclass does the special handling of uid=0 users. This is a wart since none of the rest of the (low-level) API includes this support. (setusercontext and setclasscontext inherit the behaviour.) This wart appears to be the origin of the sshd bug: although sshd calls setusercontext, setusercontext doesn't call getpwclass if the login_cap_t argument has been initialized, and sshd initializes it incorrectly. It turns out to be quite easy to fix sshd though :-) (A general observation: there appear to be a number of incorrect comments in the source for libutil which is rather irritating.) --- session.c 3 Dec 2001 00:53:28 -0000 1.4.2.11 +++ session.c 24 Apr 2002 13:56:44 -0000 @@ -149,7 +149,7 @@ startup_pipe = -1; } #ifdef HAVE_LOGIN_CAP - if ((lc = login_getclass(authctxt->pw->pw_class)) == NULL) { + if ((lc = login_getpwclass(authctxt->pw)) == NULL) { error("unable to get login class"); return; } How-To-Repeat: I added a :umask=002: entry to the default login class and a :umask=022: entry to the root login class in </etc/login.conf>. After this, if root logs in via a getty on a virtual console or via telnet, the umask is 022 as expected, but if root logs in via ssh the umask is 002. However, if root's password entry is changed to mention the root login class explicitly, the umask is set to 022 when root logs in via ssh.