documentation bug (uid resetting in posix mode)

[Stefano Lattarini]

>From experimenting, I've found out that bash (4.2.20), when invoked
as "sh", doesn't reset the effective user id to the real user id,
even if called *without* the '-p' option.

This behaviour seems consistent with that of other POSIX shells like
dash (0.5.7) and ksh (JM 93u+ 2012-02-29), so I believe bash is
correct here.

However, I couldn't find mention of such behaviour in the manual,
which is rather confusing.

Am I missing something, or have I found a bug in the manual?

Regards,
Stefano

[Andreas Schwab]

Stefano Lattarini <stefano....@gmail.com> writes:

>>From experimenting, I've found out that bash (4.2.20), when invoked
> as "sh", doesn't reset the effective user id to the real user id,
> even if called *without* the '-p' option.

How did you test that?

# ls -l sh
-rwsr-xr-x 1 nobody root 755512 30. Okt 17:03 sh
# ./sh -c id
uid=0(root) gid=0(root) groups=0(root)
# ./sh -p -c id
uid=0(root) gid=0(root) euid=65534(nobody) groups=65533(nobody),0(root)

Andreas.

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Stefano Lattarini]

On 10/30/2012 05:06 PM, Andreas Schwab wrote:
> Stefano Lattarini <stefano....@gmail.com> writes:
>
>> From experimenting, I've found out that bash (4.2.20), when invoked
>> as "sh", doesn't reset the effective user id to the real user id,
>> even if called *without* the '-p' option.
>
> How did you test that?
>

Here we go:

$ cat print-uids.c
#define _GNU_SOURCE
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
int main (void)
{
uid_t ruid, euid, suid;
getresuid (&ruid, &euid, &suid);
printf ("[%d] ruid = %d, euid = %d, suid = %d\n",
getpid(), ruid, euid, suid);
return 0;
}

$ cat system-suid.c | sed 's/^/ /'
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>
int main (void)
{
return system(
"./print-uids"
" && "
"echo {$$} uid: $UID, euid: $EUID"
" && "
"/bin/sh -c 'echo sh{$$} uid: $UID, euid: $EUID'"
" && "
"/bin/bash -c 'echo bash4{$$} uid: $UID, euid: $EUID'"
" && "
"bash-3.0 -c 'echo bash3{$$} uid: $UID, euid: $EUID'"
" && "
"bash-2.0 -c 'echo bash2{$$} uid: $UID, euid: $EUID'"
" && "
"ksh -c 'echo ksh{$$} uid: $(id -r -u), euid: $(id -u)'"
" && "
"dash -c 'echo dash{$$} uid: $(id -r -u), euid: $(id -u)'"
);
}

$ cc -o print-uids print-uids.c
$ cc -o system-suid system-suid.c

$ su -c 'chown root system-suid && chmod u+s system-suid'
Password: ********

$ ls -l system-suid print-uids
-rwxr-xr-x 1 stefano stefano 5167 Oct 30 17:58 print-uids
-rwsr-xr-x 1 root stefano 5293 Oct 30 17:59 system-suid

$ ./system-suid
[8204] ruid = 1000, euid = 0, suid = 0
{8203} uid: 1000, euid: 0
sh{8205} uid: 1000, euid: 0
bash4{8206} uid: 1000, euid: 1000
bash3{8207} uid: 1000, euid: 1000
bash2{8208} uid: 1000, euid: 1000
ksh{8209} uid: 1000, euid: 0
dash{8212} uid: 1000, euid: 0

HTH,
Stefano

[Andreas Schwab]

Stefano Lattarini <stefano....@gmail.com> writes:

> $ ./system-suid
> [8204] ruid = 1000, euid = 0, suid = 0

Looks like your /bin/sh is broken.

[Stefano Lattarini]

On 10/30/2012 06:28 PM, Andreas Schwab wrote:
> Stefano Lattarini <stefano....@gmail.com> writes:
>
>> $ ./system-suid
>> [8204] ruid = 1000, euid = 0, suid = 0
>
> Looks like your /bin/sh is broken.
>

How "broken" exactly? Honest question.

Anyway, my /bin/sh is bash ...

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh -> bash

$ /bin/sh --version
GNU bash, version 4.2.20(1)-release (i486-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I'm on Debian Unstable BTW (sorry for not specifying that earlier).

Let me know if you need more information.

Regards,
Stefano

[Chet Ramey]

On 10/30/12 1:53 PM, Stefano Lattarini wrote:
> On 10/30/2012 06:28 PM, Andreas Schwab wrote:
>> Stefano Lattarini <stefano....@gmail.com> writes:
>>
>>> $ ./system-suid
>>> [8204] ruid = 1000, euid = 0, suid = 0
>>
>> Looks like your /bin/sh is broken.
>>
> How "broken" exactly? Honest question.

It's not unheard of for vendors to make their own changes and ship the
result. This has happened a number of times in the past.

>
> Anyway, my /bin/sh is bash ...
>
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh -> bash
>
> $ /bin/sh --version
> GNU bash, version 4.2.20(1)-release (i486-pc-linux-gnu)
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> I'm on Debian Unstable BTW (sorry for not specifying that earlier).

You should open a bug report with Debian. This behavior has been noted
previously; look at one of the footnotes to answer 2 in

http://stackoverflow.com/questions/556194/calling-a-script-from-a-setuid-root-c-program-script-does-not-run-as-root

for example.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/

[Bob Proulx]

Stefano Lattarini wrote:
> Anyway, my /bin/sh is bash ...
> $ ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh -> bash

> I'm on Debian Unstable BTW (sorry for not specifying that earlier).

Let me say this aside on the issue since there is opportunity for some
confusion. On Debian the default for new installations is that
/bin/sh is a symlink to dash. But existing systems that are upgraded
will not get this change automatically and will remain as a symlink to
bash. It must be specifically selected if desired. Therefore the
selection of /bin/sh is bi-modal with many systems of either
configuration. The dash NEWS file says:

* The default system shell (/bin/sh) has been changed to dash for
new installations. When upgrading existing installations, the
system shell will not be changed automatically.
* One can see what the current default system shell on this machine
is by running 'readlink /bin/sh'.
* Change it by running 'dpkg-reconfigure dash'.

The 'dpkg-reconfigure dash' will present a question with the previous
value allowing the admin to reconfigure it to a different value. The
selected value is sticky and will persist through upgrades until changed.

Bob

[Chet Ramey]

> Stefano Lattarini wrote:
> > Anyway, my /bin/sh is bash ...
> > $ ls -l /bin/sh
> > lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh -> bash
> > I'm on Debian Unstable BTW (sorry for not specifying that earlier).
>
> Let me say this aside on the issue since there is opportunity for some
> confusion. On Debian the default for new installations is that
> /bin/sh is a symlink to dash. But existing systems that are upgraded
> will not get this change automatically and will remain as a symlink to
> bash. It must be specifically selected if desired.

Either way, it doesn't matter. This is from the debian system(3) man page:

"Do not use system() from a program with set-user-ID or set-group-ID
privileges, because strange values for some environment variables
might be used to subvert system integrity. Use the exec(3) family of
functions instead, but not execlp(3) or execvp(3). system() will not,
in fact, work properly from programs with set-user-ID or set-group-ID
privileges on systems on which /bin/sh is bash version 2, since bash 2
drops privileges on startup. (Debian uses a modified bash which does
not do this when invoked as sh.)"

Though it only references version 2, I assume that debian has continued
the practice of modifying bash.

[Stefano Lattarini]

Hi Chet.

On 10/30/2012 07:10 PM, Chet Ramey wrote:
> On 10/30/12 1:53 PM, Stefano Lattarini wrote:
>> On 10/30/2012 06:28 PM, Andreas Schwab wrote:
>>> Stefano Lattarini <stefano....@gmail.com> writes:
>>>
>>>> $ ./system-suid
>>>> [8204] ruid = 1000, euid = 0, suid = 0
>>>
>>> Looks like your /bin/sh is broken.
>>>
>> How "broken" exactly? Honest question.
>
> It's not unheard of for vendors to make their own changes and ship the
> result. This has happened a number of times in the past.
>

You're right; I see this in the bash_4.2-5.diff file applied by Debian:

--- bash-4.2.orig/debian/patches/privmode.diff
+++ bash-4.2/debian/patches/privmode.diff
@@ -0,0 +1,19 @@
# DP: XXX missing description
# DP:
# DP: Comment from Chet Ramey <ch...@nike.ins.cwru.edu>:
# DP:
# DP: Nope. This will allow setuid scripts if not called as `sh' and not
# DP: called with the -p option. I won't install this.

--- a/bash/shell.c
+++ b/bash/shell.c
@@ -486,7 +486,7 @@
if (dump_translatable_strings)
read_but_dont_execute = 1;

- if (running_setuid && privileged_mode == 0)
+ if (running_setuid && privileged_mode == 0 && act_like_sh == 0)
disable_priv_mode ();

So the behaviour I'm seeing is only due to the Debian patches, and
there's no bug in the Bash documentation.

Thanks, and sorry for the noise,
Stefano

[Stefano Lattarini]

Hi Bob, thanks for the tips. However ...

On 10/30/2012 07:37 PM, Bob Proulx wrote:
> Stefano Lattarini wrote:
>> Anyway, my /bin/sh is bash ...
>> $ ls -l /bin/sh
>> lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh -> bash
>> I'm on Debian Unstable BTW (sorry for not specifying that earlier).
>
> Let me say this aside on the issue since there is opportunity for some
> confusion. On Debian the default for new installations is that
> /bin/sh is a symlink to dash. But existing systems that are upgraded
> will not get this change automatically and will remain as a symlink to
> bash. It must be specifically selected if desired.
>

... I'm not so sure all of scripts on my system are exempt from
bashisms; so rather than risking obscure bugs, I'll keep bash as
my system shell (for the current system, at least). If it ain't
broken, don't fix it ;-)

Best regards,
Stefano

[Andreas Schwab]

Stefano Lattarini <stefano....@gmail.com> writes:

> If it ain't broken, don't fix it ;-)

As you found out, it _is_ broken.

[Bob Proulx]

Stefano Lattarini wrote:
> Hi Bob, thanks for the tips. However ...
>

> Bob Proulx wrote:
> > Stefano Lattarini wrote:
> >> Anyway, my /bin/sh is bash ...
> >> $ ls -l /bin/sh
> >> lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh -> bash
> >> I'm on Debian Unstable BTW (sorry for not specifying that earlier).
> >
> > Let me say this aside on the issue since there is opportunity for some
> > confusion. On Debian the default for new installations is that
> > /bin/sh is a symlink to dash. But existing systems that are upgraded
> > will not get this change automatically and will remain as a symlink to
> > bash. It must be specifically selected if desired.
> >
> ... I'm not so sure all of scripts on my system are exempt from
> bashisms; so rather than risking obscure bugs, I'll keep bash as

> my system shell (for the current system, at least). If it ain't

> broken, don't fix it ;-)

I wasn't suggesting that you change it. I was simply noting that the
symlink has two standard values. Which has caused confusion elsewhere
concerning whether it was bash behavior or dash behavior. There isn't
a canonical configuration.

Knowledge is power, and all of that.

Bob

[Bob Proulx]

Andreas Schwab wrote:

> Stefano Lattarini writes:
> > If it ain't broken, don't fix it ;-)
>

> As you found out, it _is_ broken.

Okay. But broken which way? Which of these are you saying:

1. Broken because bash normally drops privileges?
Or:
2. Broken because called as /bin/sh Debian patched it to not drop
privileges?
Or:
3. ??

Bob

[Stefano Lattarini]

On 10/30/2012 08:24 PM, Andreas Schwab wrote:

> Stefano Lattarini <stefano....@gmail.com> writes:
>
>> If it ain't broken, don't fix it ;-)
>
> As you found out, it _is_ broken.
>

Actually, I was speaking about the fact that, even after reading
Bob's explanation about how to make dash the /bin/sh of a Debian
system, I'll stuck with Bash, to avoid potential useless breakage
on my system. So ``if the system isn't broken having bash as
/bin/sh, don't "fix" it putting dash in /bin/sh''.

I have no strong feelings about the "ruid/euid synchronization"
behaviour (my only gripe is that Debian hasn't updated the man
page as well after changing the bash behaviour).

Regards,
Stefano

[Stefano Lattarini]

On 10/30/2012 08:31 PM, Bob Proulx wrote:
>
> [MEGA-SNIP]

>
> Knowledge is power, and all of that.
>

Agreed. In fact, I wasn't aware of he possibility you described,
so I really appreciated your explanation. It wasn't my intention
to appear to dismissive of it; I apologize if I gave that
impression.

Thanks,
Stefano