Date: Wed, 21 Jan 2004 11:37:33 +0900 (JST) From: NAKAJI Hiroyuki <nakaji@jp.freebsd.org> To: FreeBSD-gnats-submit@FreeBSD.org Cc: dwcjr@FreeBSD.org Subject: ports/61662: [japanese/samba] broken support for password changing via CTRL-ALT-DEL on Windows client Message-ID: <200401210237.i0L2bXjk092425@boggy.acest.tutrp.tut.ac.jp> Resent-Message-ID: <200401210240.i0L2e73v007894@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 61662 >Category: ports >Synopsis: [japanese/samba] broken support for password changing via CTRL-ALT-DEL on Windows client >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-ports-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jan 20 18:40:07 PST 2004 >Closed-Date: >Last-Modified: >Originator: NAKAJI Hiroyuki >Release: FreeBSD 5.2-CURRENT i386 >Organization: >Environment: System: FreeBSD boggy.acest.tutrp.tut.ac.jp 5.2-CURRENT FreeBSD 5.2-CURRENT #19: Tue Jan 20 15:27:30 JST 2004 root@boggy.acest.tutrp.tut.ac.jp:/usr/obj/usr/src/sys/NAKAJI i386 >Description: As reported in ports/60361 and ports/52859, japanese/samba also has a problem that "users cannot change password from their windows". This is because of the failure of setresgid() called from lib/util_sec.c:restore_re_gid(). The setresgid(2) says, "Unprivileged processes are restricted in that each of the new IDs must match one of the current IDs." It seems that this "Unprivileged process" is such a process whose "effective uid or gid" is not zero. I checked every return value of setresgid() in lib/util_sec.c:restore_re_gid(), and found that before smbd gets PANIC, setresgid() fails with EPERM because it is called with the both non-zero effective uid and gid before restore_re_gid() is called. When getresgid() fails and results into smbd panic, the effective uid and gid are not 0 but the uid and gid of a user who wants to change his or her password (or nobody). The patch posted in ports/60361 is not good because it does not solve the problem and just does not see the 'security check failed' problem. It may cause some other security problems. The Samba Users Group Japan (SUGJ) helped me very much. Thanks. Note: Discussion on this topic in Japanese is available, see http://www.samba.gr.jp/ml/article/samba-jp/msg15772.html and http://www.samba.gr.jp/ml/article/sugj-tech/msg06065.html >How-To-Repeat: Setup your samba as PDC or password server, and then try to change your password from your Windows client. >Fix: A diff from ports-current. New patch file is added. diff -urN -x CVS /usr/ports/japanese/samba/Makefile ./Makefile --- /usr/ports/japanese/samba/Makefile Tue Jan 20 14:24:21 2004 +++ ./Makefile Wed Jan 21 10:55:30 2004 @@ -7,7 +7,7 @@ PORTNAME= samba PORTVERSION= ${SAMBA_VERSION}.j${SAMBA_JA_VERSION} -PORTREVISION= 3 +PORTREVISION= 4 CATEGORIES= japanese net MASTER_SITES= ftp://ftp.samba.gr.jp/pub/samba-jp/%SUBDIR%/ \ ftp://ftp.iij.ad.jp/pub/SAMBA/samba-jp/%SUBDIR%/ \ diff -urN -x CVS /usr/ports/japanese/samba/files/patch-lib:util_sec.c ./files/patch-lib:util_sec.c --- /usr/ports/japanese/samba/files/patch-lib:util_sec.c Thu Jan 1 09:00:00 1970 +++ ./files/patch-lib:util_sec.c Wed Jan 21 10:34:24 2004 @@ -0,0 +1,26 @@ +Index: lib/util_sec.c +=================================================================== +RCS file: /project/cvs/samba22-ja/source/lib/util_sec.c,v +retrieving revision 1.4 +diff -u -r1.4 util_sec.c +--- lib/util_sec.c 21 Nov 2002 12:53:49 -0000 1.4 ++++ lib/util_sec.c 21 Jan 2004 01:31:37 -0000 +@@ -283,6 +283,10 @@ + + void restore_re_gid(void) + { ++ uid_t uid = geteuid(); ++ ++ set_effective_uid(0); ++ + #if USE_SETRESUID + setresgid(saved_rgid, saved_egid, -1); + #elif USE_SETREUID +@@ -298,6 +302,7 @@ + set_effective_gid(saved_egid); + #endif + ++ set_effective_uid(uid); + assert_gid(saved_rgid, saved_egid); + } + >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401210237.i0L2bXjk092425>