> On Tue, May 9, 2017 at 4:17 PM, Ted Unangst <t...@tedunangst.com> wrote: > > Matthew Martin wrote: > > I would suggest N^2 loops are automatically forgiveable, If there > is a limit on N, > which is a reasonable number for any supported environment, but total > potential > impact on performance for launching a process could be worth considering. > > Also, what the impact will be when an application constructs a > 4-Megabyte envp with a > million environment variables passed through envp. > > And I would question: What is the basis for rejecting an environment > that differs from the > structure that Sh, Bash, or Tcsh expects ? > > By convention Shell environments use Name=Value lines, and so do C > library utilities > such as getenv(). > > But as far as I know, Applications are allowed to pass arbitrary data > to one another > using the envp environment blob, or may use other delimiters besides = > within string data which the caller and callee agree upon, And there are > Probably useful reasons for doing so.
POSIX says ``conforming applications are required not to modify environ directly'' and specifically warns about doing so in a multithreaded application. It also says that the strings have the form name=value and that if more than one string in the environment has the same name the results are undefined. So a conforming application cannot create duplicate entries or entries without an = sign. As we know, there's a lot of buggy software. A couple recent bugs were mentioned in the IRC channel: https://www.sudo.ws/repos/sudo/rev/d4dfb05db5d7 https://lists.debian.org/debian-security-announce/2016/msg00072.html https://sourceware.org/bugzilla/show_bug.cgi?id=19749 A duplicate PATH would be set and the shell would display one and e.g. sudo would use the other. (Of course you have to be in a position to set environment variables to do this attack.) It would be interesting to see if there's actually any misbehaving applications. Martin > > Maybe fix this in the C library utility functions instead where more > assumptions > about the runtime environment may be implied.... > > > I would suggest handling invalid or not-understood entries by ignoring > them or skipping > the entry, when querying the environment in the C library. > > I would suggest handling duplicates by adopting a consistent search rule, > such as getenv("A") will Only return the last A=B entry in the list; > putenv("A=B") will always replace the last entry in the list, and > ignore preceding occurences. > > > >> Duplicate environment variables have been a source of bugs, so perhaps > >> the kernel should fail an execve with an invalid envp. Diff below checks > >> that each environment string contains a '=' and that there are no > >> duplicates up to the equals sign. > > > > It's not really the kernel's job to save you from yourself. Also, you're > > adding a n^2 loop in the kernel, which is not good. > -- > -JH > >
