Bug #1341

[PATCH]: printenv(1): don't allow '=' in name

Added by Anonymous over 5 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Salute.

After the recent libc changes, we no more allow environmental variables to have
an '=' character in their name. The printenv(1) utility isn't aware of that, so
it embarrasses itself, along with misleading the user:

$ env foo=bar=lala=123 printenv foo
bar=lala=123
$ env foo=bar=lala=123 printenv foo=bar
lala=123
$ env foo=bar=lala=123 printenv foo=bar=lala
123

In the above example, it gives the impression that there are 3 distinct
variables with names: foo, foo=bar, foo=bar=lala, which is wrong.

After the patch:

$ env foo=bar=lala=123 printenv foo
bar=lala=123
$ env foo=bar=lala=123 printenv foo=bar
printenv: variable name can't contain an '=' character
$

What do you think ? Ship it ?

Cheers,
Stathis

printenv.diff Magnifier (563 Bytes) Anonymous, 04/20/2009 06:58 PM

History

#1 Updated by dillon over 5 years ago

:After the recent libc changes, we no more allow environmental variables to =
:have
:an '=3D' character in their name. The printenv(1) utility isn't aware of th=
:at, so
:it embarrasses itself, along with misleading the user:
:..
:
:What do you think ? Ship it ?
:
:Cheers,
:Stathis

No, it definitely should not exit if it is asked to display an
environment variable with '=' in it. It could print a warning
to stderr, though, but I don't think it's necessary. If the
environment variable isn't supposed to exist then it won't find
it. If the environment variable does exist it is not printenv's
job to check whether it is legal or not.

-Matt

#2 Updated by Anonymous over 5 years ago

: If the environment variable isn't supposed to exist then it won't find it.
: If the environment variable does exist it is not printenv's job to check
: whether it is legal or not.

True, but printenv isn't very good at deciding if a variable exists in an
environment or not, in case the name contains an '='.

Here is an example. Let's say that there is a variable named "foo" that equals
"bar=123" and we ask from printenv to print the variable "foo=bar" (which
obviously doesn't exist). Here is what happens:

For every "name=value" pair inside the environment, printenv invokes a memcmp
between the currently examined variable and the target, of at most `len' bytes.
Where `len' is the length of the target. So, memcmp("foo=bar", "foo=bar=123", 7)
actually returns a match, although "foo=bar" doesn't correspond to a real variable.

I hope I didn't confuse things more.

Cheers,
Stathis

#3 Updated by dillon over 5 years ago

:Stathis Kamperis <> added the comment:
:
:...
:ch
:obviously doesn't exist). Here is what happens:=20
:
:For every "name=3Dvalue" pair inside the environment, printenv invokes a me=
:mcmp
:between the currently examined variable and the target, of at most `len' by=
:tes.
:Where `len' is the length of the target. So, memcmp("foo=3Dbar", "foo=3Dbar=
:=3D123", 7)
:actually returns a match, although "foo=3Dbar" doesn't correspond to a real=
: variable.
:
:I hope I didn't confuse things more.
:
:Cheers,
:Stathis

It sounds to me that printenv's environment search is what needs to
be fixed. The environ has one environment variable per array entry.
instead of doing the memcmp() it should iterate forwards looking for
the first '=', then do a length check and, if the length matches,
finally a memcmp().

-Matt
Matthew Dillon
<>

#4 Updated by Anonymous over 5 years ago

: It sounds to me that printenv's environment search is what needs to
: be fixed. The environ has one environment variable per array entry.
: instead of doing the memcmp() it should iterate forwards looking for
: the first '=', then do a length check and, if the length matches,
: finally a memcmp().

They way you put it, seems more reasonable to me.
I attached a new diff.

Cheers,
Stathis

#5 Updated by alexh over 5 years ago

Wasn't this already commited? I remember seeing something about '='s in some env
function.

#6 Updated by Anonymous over 5 years ago

: Wasn't this already commited?
: I remember seeing something about '='s in some env function.

Hey alexh. That patch was about setenv(3), which is now fixed.
printenv(3) needs to be fixed as well.

Cheers,
Stathis

#7 Updated by alexh over 5 years ago

Oh, I'm sorry, I mixed those two up.
I'm renaming it if you don't mind so it is easier to see that there is a diff
already, to [PATCH]: ....

#8 Updated by Anonymous over 5 years ago

I am going to push this tomorrow or the day after, unless someone objects.

Just for the record, I have filed a PR in NetBSD bug database as well and they
fixed it differently:

...
if (argc != 1)
usage();
if (strchr(*argv, '=') != NULL)
errx(1, "Invalid environment variable %s", *argv);
len = strlen(*argv);
for (ep = environ; *ep; ep++)
...

POSIX says that env vars shouldn't contain an '=' sign and functions as
setenv(3) fail with EINVAL if the supplied name contains an equal sign.

Cheers,
Stathis

Also available in: Atom PDF