[Pkg-shadow-devel] Bug#479406: su fails for users with a POSIX script as their login shell

[Nicolas François]

severity 479406 wishlist
thanks

Hello,

On Sun, May 04, 2008 at 05:46:49PM +0100, Stephane Chazelas wrote:
> 
> (Note that the same applies to "login").
> 
> With this password entry:
> 
> test:x:1000:1000:test:/:/tmp/x
> 
> And /tmp/x being an executable file containing this only line:
> echo test
[...]
> 
> Although not widely known that way of writing shell scripts is
> *the* standard (POSIX and Unix) way. The behavior is unspecified
> as per POSIX if your file starts with "#!".

I would definitely prefer that the admin define the shell that has to
interpret the file.

Yes, it is mentioned in
http://www.opengroup.org/onlinepubs/9699919799/functions/exec.html ,
but is it a common practice to have a shell script as a shell and that the
shell which should interpret that script is not specified?

An option could be to use execlp or execvp, and also make sure the shell
is an absolute path.

> All the utilities specified by POSIX and that may execute
> commands (sh, env, exec, ex, vi, awk...) and the
> execvp/execlp/system/popen libc functions are meant to recognise
> those files (the text files that don't start with #!): upon a
> ENOEXEC, they should have the file interpreted by a standard
> sh.

I did not find any usage of ENOEXEC/execlp/execvp in elvis, nvi, mawk, gawk.
They probably use system().

I'm not really a surprise that sh, env, and exec do that but it will be
much easier for them to choose the shell.

> I'll concede login and su are not specified by POSIX, but it
> would make more sense that they behave the same way as other
> standard utilities.

Are there other su / login implementations which behave that way?

On Mon, 5 May 2008 11:18:47 +0100, Stephane Chazelas wrote:
>
> BTW, this code (thanksfully disabled on Linux) is wrong:
> 
>         /* Linux handles #! in the kernel, and bash doesn't make
>            sense of "#!" so it wouldn't work anyway...  --marekm */
> #ifndef __linux__
>[...]

Yes, this should be removed.

Best Regards,
-- 
Nekral