[Bug 268479] lib/libc/stdlib/getenv.c may have a problem with putenv()

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268479

--- Comment #12 from Dennis Clarke <dclarke@blastwave.org> ---
(In reply to Mark Millard from comment #11)


Firstly, thank you for looking at this "thing" which may not be any sort
of a bug at all. However it is surely very strange behavior! Only on a
FreeBSD system can I entirely override the data from uname as a user.

See : 

callisto$ 
callisto$ uname -apKU 
FreeBSD callisto 13.1-RELEASE-p3 WAT_THE_FUCK amd64 amd64 1301000 1301000
callisto$ 
callisto$ UNAME_s=  UNAME_n= UNAME_r= UNAME_v= UNAME_m= UNAME_p= UNAME_i=
UNAME_K= UNAME_U= UNAME_b=  uname -apKU | od -Ax -t x1 -v 
0000000    20  20  20  20  20  20  20  0a                                
0000008
callisto$ 

Well that is a real surprise.

Looking in ./usr.bin/uname/uname.c   where I see the wild macro :

000156
000157  #define CHECK_ENV(opt,var)                              \
000158  do {                                                    \
000159          if ((var = getenv("UNAME_" opt)) == NULL) {     \
000160                  get_##var = native_##var;               \
000161          } else {                                        \
000162                  get_##var = (get_t)NULL;                \
000163          }                                               \
000164  } while (0)
000165
000166  static void
000167  setup_get(void)
000168  {
000169          CHECK_ENV("s", sysname);
000170          CHECK_ENV("n", hostname);
000171          CHECK_ENV("r", release);
000172          CHECK_ENV("v", version);
000173          CHECK_ENV("m", platform);
000174          CHECK_ENV("p", arch);
000175          CHECK_ENV("i", ident);
000176          CHECK_ENV("K", kernvers);
000177          CHECK_ENV("U", uservers);
000178          CHECK_ENV("b", buildid);
000179  }
000180

So therefore the man page for UNAME(3) barely touches the true state of
affairs for a user process! We can entirely hide the system data with a
few env vars. So, to me, this seems like a great thing to "undo" where I
the user can actually know the system we are running on.  That means we
need to walk around in **environ and hope the memory is contiguous?  To
me the environ pointer is somewhere mystical and not at all on the stack
or even someplace I should mess with. I have to go digging into the core
code on this and see if I can wreck havok with that array of pointers? 

In any case this is interesting as I never expected to run a process and
not know the actual system description. Very curious and also fun. 


Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

-- 
You are receiving this mail because:
You are the assignee for the bug.