openssh unix dev - Nov 2010 - test request: SCO with setluid() (i686-pc-sco3.2v5.0.7, possibly others)

Hi all.

I am cleaning up (I hope) one of the nastier pieces of code in openssh:
do_setusercontext which is/was a twisty maze of platform-specific
nested ifdefs.  I made a series of changes[1] where I moved each
platform-specific piece into a portable-only file platform.c, which does
not need to be kept in sync with OpenBSD.

The changes did not (I hope!) change the semantics, but there's one
change I'd like to make that doesn't fit into the new scheme: the code
that calls setluid.  The code in question dates back to at least 2001 and
I suspect its current location is mere historical accident.  Based on
some cvs archaeology and looking at the survey[2] data, I believe this
only affects SCO platforms, possibly limited to *-pc-sco3.2v*.

If anyone is still in possesion of such a beast, could you please try
the patch below (against today's snapshot or newer) and see if it still
behaves as expected?

Thanks.

[1] http://anoncvs.mindrot.org/index.cgi/openssh/session.c?r1=1.398&r2=1.408

[2] plug: have you sent survey info for your platform?  if not, try "make
survey"!

Index: platform.c
==================================================================RCS file:
/var/cvs/openssh/platform.c,v
retrieving revision 1.14
diff -u -p -r1.14 platform.c
--- platform.c	5 Nov 2010 03:47:01 -0000	1.14
+++ platform.c	5 Nov 2010 04:08:42 -0000
@@ -109,6 +109,14 @@ platform_setusercontext(struct passwd *p
 		}
 	}
 # endif /* USE_PAM */
+
+#if !defined(HAVE_LOGIN_CAP) && defined(HAVE_GETLUID) &&
defined(HAVE_SETLUID)
+	if (getuid() == 0 || geteuid() == 0) {
+		/* Sets login uid for accounting */
+		if (getluid() == -1 && setluid(pw->pw_uid) == -1)
+			error("setluid: %s", strerror(errno));
+	}
+#endif
 }
 
 /*
Index: session.c
==================================================================RCS file:
/var/cvs/openssh/session.c,v
retrieving revision 1.408
diff -u -p -r1.408 session.c
--- session.c	5 Nov 2010 03:47:01 -0000	1.408
+++ session.c	5 Nov 2010 04:08:42 -0000
@@ -1479,12 +1479,6 @@ do_setusercontext(struct passwd *pw)
 			exit(1);
 		}
 #else
-# if defined(HAVE_GETLUID) && defined(HAVE_SETLUID)
-		/* Sets login uid for accounting */
-		if (getluid() == -1 && setluid(pw->pw_uid) == -1)
-			error("setluid: %s", strerror(errno));
-# endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */
-
 		if (setlogin(pw->pw_name) < 0)
 			error("setlogin failed: %s", strerror(errno));
 		if (setgid(pw->pw_gid) < 0) {

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Hi,

On Fri, Nov 05, 2010 at 03:15:33PM +1100, Darren Tucker
wrote:
> The changes did not (I hope!) change the semantics, but there's one
> change I'd like to make that doesn't fit into the new scheme: the
code
> that calls setluid.  The code in question dates back to at least 2001 and
> I suspect its current location is mere historical accident.  Based on
> some cvs archaeology and looking at the survey[2] data, I believe this
> only affects SCO platforms, possibly limited to *-pc-sco3.2v*.
I can try building on a SCO OSR 3.0 (sco3.2v4.2) or SCO OSE 5 (sco3.2v5)
system.  Will investigate this weekend.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at
greenie.muc.de
fax: +49-89-35655025                        gert at
net.informatik.tu-muenchen.de

On Fri, 5 Nov 2010, Darren Tucker wrote:
> The changes did not (I hope!) change the semantics, but there's one
> change I'd like to make that doesn't fit into the new scheme: the
code
> that calls setluid.  The code in question dates back to at least 2001 and
> I suspect its current location is mere historical accident.  Based on
Well, in do_setusercontext() does look apropriate to me.
> some cvs archaeology and looking at the survey[2] data, I believe this
> only affects SCO platforms, possibly limited to *-pc-sco3.2v*.
And *-*-sysv5SCO_SV*
> If anyone is still in possesion of such a beast, could you please try
> the patch below (against today's snapshot or newer) and see if it still
> behaves as expected?
The patch looks good. I'll build and run on a couple of machines here
and let you know.

-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net