From seanc@FreeBSD.org  Wed Jan 15 12:40:03 2003
Return-Path: <seanc@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id B893137B401
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 15 Jan 2003 12:40:03 -0800 (PST)
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 60C7643EB2
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 15 Jan 2003 12:40:03 -0800 (PST)
	(envelope-from seanc@FreeBSD.org)
Received: from freefall.freebsd.org (seanc@localhost [127.0.0.1])
	by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h0FKe3NS014773
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 15 Jan 2003 12:40:03 -0800 (PST)
	(envelope-from seanc@freefall.freebsd.org)
Received: (from seanc@localhost)
	by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h0FKe3Rg014772;
	Wed, 15 Jan 2003 12:40:03 -0800 (PST)
Message-Id: <200301152040.h0FKe3Rg014772@freefall.freebsd.org>
Date: Wed, 15 Jan 2003 12:40:03 -0800 (PST)
From: Sean Chittenden <seanc@freebsd.org>
Reply-To: Sean Chittenden <seanc@freebsd.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Unable to su to root after root run's a command that runs as a different user
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         47119
>Category:       kern
>Synopsis:       Unable to su to root after root run's a command that runs as a different user
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    mtm
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 15 12:50:02 PST 2003
>Closed-Date:    Wed Jan 15 20:27:04 PST 2003
>Last-Modified:  Wed Jan 15 20:27:04 PST 2003
>Originator:     Sean Chittenden
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD dsl093-135-251.sfo2.dsl.speakeasy.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Jan 12 12:32:11 PST 2003 root@dsl093-135-251.sfo2.dsl.speakeasy.net:/usr/obj/usr/src/sys/DELLAPTOP i386

>Description:
	Run the following program.  Once run, and root exist, a member of the
	wheel group won't be able to su to root again.
>How-To-Repeat:
$ gcc -o su_test su_test.c
$ su
# ./su_test
running as user 80 now
# exit
$ su
su: Sorry

/* BEGIN su_test.c */
#include <unistd.h>
#include <sys/types.h>
#include <stdio.h>
#include <pwd.h>

int main() {
  struct passwd* pwd;
  uid_t uid;
  gid_t gid;
  int ngroups;
  char *user = "www";

  pwd = getpwnam(user);
  uid = pwd->pw_uid;
  gid = pwd->pw_gid;

  if (chdir(pwd->pw_dir) < 0) {
    perror( "chdir" );
    exit(1);
  }

  setsid();

  if (chroot("/") < 0) {
    perror( "chroot" );
    exit(1);
  }

  if (chdir("/") < 0) {
    perror("chroot chdir");
    exit(1);
  }

  if (setgroups(0, (const gid_t*) 0) < 0) {
    perror("setgroups");
    exit(1);
  }

  if (setgid(gid) < 0) {
    perror("setgid");
    exit(1);
  }

  setlogin(user);

  if (setuid(uid) < 0) {
    perror("setuid");
    exit(1);
  }

  uid = getuid();
  printf("running as user %d now\n", uid);

  exit(0);
}
/* END su_test.c */

>Fix:

	


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: mtm 
State-Changed-When: Wed Jan 15 17:57:19 PST 2003 
State-Changed-Why:  
This is my prelimanry finding: 
The problem is that when the user associated with the session is 
changed it propagates back to the parent, even though setsid(2) 
has been called. You are not able to su(1) after the program 
has completed because the user associated with the session (the 
login user) after the program has run is 'www'. 

I'll investigate some more and figure out if this should be 
expected, if the man page is wrong and calling setsid(2) is 
insufficient to completely disassociate from the parent's session, 
or if there is a bug somewhere. 


Responsible-Changed-From-To: freebsd-bugs->mtm 
Responsible-Changed-By: mtm 
Responsible-Changed-When: Wed Jan 15 17:57:19 PST 2003 
Responsible-Changed-Why:  
This looks interesting. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47119 
State-Changed-From-To: analyzed->closed 
State-Changed-By: mtm 
State-Changed-When: Wed Jan 15 20:21:32 PST 2003 
State-Changed-Why:  
I looked at it some more... before finally checking the 
obvious. The call to setsid() fails because you have the 
controlling terminal and you are the process group leader. 
So, the call to setlogin() is really changing the login 
name of your login session (as it should). The bug 
is in the program. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47119 
>Unformatted:
