Hi,
V ?t, 24. 03. 2009 v 23:03, David Korn p??e:
> Subject: ksh -p
> --------
>
> > I'm seeing a bug in ksh93 when run with rgid != egid (and ruid==0),
> > where rgid is being set inappropriately and changing as a side effect of
> > a simple test of file mode.
> >
> > The result is that issetugid() returns 0 when it should not, which
> > causes resolution of $ORIGIN in RPATH to succeed, which is a security
> > violation (see ld.so.1(1)), until a file mode is tested at which point
> > rgid reverts to its correct value and issetugid starts correctly
> > returning 1 and $ORIGIN to stop being resolved.
> >
> > I've attached a simple ksh script to demonstrate the basic problem
> > (Test.ksh), as well as a 1-line C application to report issetugid()
> > (tstissetugid.c), and the script output (test.out).
> >
> > The script can be executed (as root) as follows:
> > # perl -e ' $( = 10; $) = "50 10"; ($(, $)) = (10, 50) ; ; system
> > "pcred", $$; system "ksh93", "-p", "/tmp/Test.ksh"'
> >
> > In the test.out file, you can see that simply executing "[ -r
> > /etc/shadow ]" causes rgid to change its value.
> >
> > Strangely, if you create a shell script that simply says "exec
> > /tmp/Test.ksh" and execute *it*, the problem is not seen.
> >
> > I've reproduced this on OpenSolaris using build 109 (as well as 101b_rc2).
> >
> > Before filing a bug I thought I'd run this by the list to see if anyone
> > has anything to add/contribute.
> >
> > Casper Dik has the following to contribute:
> > > Ah, so what happens is that ksh93 calls setgid(50); unfortunately, when
> > > you're root, setgid doesn't just change the real gid; it changes all the
> > > gids
> > (strange, but true).
> > >
> > > Later, it does "setregid(50, 10); access("/etc/shadow"); setregid(10, 50)"
> > > and suddenly you have an rgid of 10:
> > >
> > <snip>
> > > I think ksh93 shouldn't play with gid/uid. Or sh did that, our ksh
> > > didn't.
> > >
> > > If we want to change this in ksh93, then we need to change the call
> > > to setgid() to setregid().
> > >
> >
> > -Bob
> >
> >
> > #!/bin/ksh -p
> > exec >/tmp/test.out 2>&1
> > set -x
> >
> > echo in main
> > /tmp/tstissetugid
> >
> > pcred $$
> > [ -r /etc/shadow ]
> >
> > pcred $$
> > echo in main 2
> > /tmp/tstissetugid
> >
>
> First of all, based on what you are reporting I assume that ksh93
> was compiled with SHOPT_P_UID set to a numerical value.
> Am I correct about this?
>
> When SHOPT_P_UID is defined, and the shell is invoked without -p,
> and the real and effective user id are not the same, and the real user
> id is greater than the value of SHOPT_P_UID, ksh is supposed to
> reset the effective user id and group id to the real user and group id.
>
> This is done to prevent C programs that are running with an
> effective user id different from the real uid from calling system()
> and having the command run by system() run with privilege.
>
> If you want to preserve the privilege, you need to run ksh -p.
> If SHOPT_P_UID is undefined at compilation or if the real user id is
> less than SHOPT_P_UID, the effective user id should not be changed
> and the -p option is enabled even if the shell was not invoked with -p.
>
> That is how is should have worked. However, there is a bug and
> the check of the real user id against SHOPT_P_UID was reversed so
> that real user ids less than SHOPT_P_UID were resetting the effective
> user and group id.
>
> We didn't detect this bug since we have been building with SHOPT_P_UID
> undefined.
>
>
I do not see SHOPT_P_UID defined in ON integration at all:
http://src.opensolaris.org/source/search?q=SHOPT_P_UID&defs=&refs=&path=&hist=&project=%2Fonnv
Bob, could you fill the bug, please?
Best regards,
Milan
