svUnescape() can return a pointer to the input argument
(if the input argument requires no unescaping or truncation).
That is actually the predominant case because most often we
store values that don't require escaping.
Optimize for that case.
This is especially important because we don't support
line continuation. Thus, with
FOO='val
bar=3'
wrong line
F2=b
F3='b
XXX=adf'
XXX2=val2
'
we now write
FOO=
#NM: FOO='val
bar=
#NM: bar=3'
#NM: wrong line
F2=b
F3=
#NM: F3='b
XXX=
#NM: XXX=adf'
XXX2=val2
#NM: '
Basically, the writer will comment out any line that is
- not all-whitespace
- not a '#' comment (possibly proceeded by whitespace)
- not a valid variable assignment
This avoids that writer writes lines that are not understood by
ifcfg-rh plugin, but interferes with initscripts. E.g.
NAME=old-name'
rm -rf /
'
becomes
NAME=new-name
#NM: rm -rf /
#NM: '
'\'', '~': must not be escaped with backslash.
Also, within double quotes the backslash escape character is only
removed before special caracters like '$' or '`'. Not in general.
Yes, it means that older versions of svEscape produced invalid escape
sequences that we now treat differently. But that is not realy
avoidable, it was a bug that needs to be fixed.
This is especially important for the team config JSON, which is expected
to contain newlines.
ANSI C quotation is bash specific, but initscripts already use #!/bin/bash.
Unfortunately, g_strescape() doesn't escape '\'' and can thus not be
used.
Also add a test that svEscape() and svUnescape() do a round-trip.
Not only consider \r and \n as candidates for ANSI C quotation, but all
ANSI control characters.
Better support parsing of shell. Now we support:
- combining values, like
FOO=a"b"
FOO=$'\n'b
- bash style ANSI C quotation ($''). This will allow us to properly
handle newlines in string values.
- comments at the end of a line (after whitespace)
FOO=val #comment
Note that this is different from a # without space
FOO=val#with#hashes
- trailing spaces are ignored like
FOO=a[space]
FOR=[space]
- history expansion via ! is not done (this is not new).
We don't support:
- line continuation like
FOO='
'
FOO=a\
b
- any form of shell expansion via $, ``.
FOO="$a"
Such values are recognized to name a variable FOO, but with an
empty value, like
FOO=%{nil}
which is not the same as a valid empty value
FOO=
- any other form of (unquoted) shell meta characters, like ; < > ( ).
This especially means, that the command invocations are invalid, like
ls -1
LANG=C ls -1
FOO1=a; FOO2=b
This also means, that spaces immidiately after the assignment are invalid:
FOO= val
Also, svUnescape() can now return %NULL to signal an invalid line like
FOO='
When
- reading a key that is defined multiple times, accept
the last occurrence.
- when deleting such a key, delete all occurrences.
- when overwriting such a key, overwrite the last occurrence
and delete any previous definitions.
It was not used and it is bad style. Especially, because
in the next commit we want to remove multiple definitions
of a key. Thus, we usually always iterate until the end.
Move the g_strchomp() inside svUnescape(). It is part of the
escaping process (although of course wrong to do, because
it accepts "FOO= bar". That will be fixed later).
Thereby, change the signature to allow in the future
to do unescape without additional copy.
svGetValue() had the meaning of returning a string, except the
empty word "" was coerced to NULL.
svGetValueFull() had the meaing of returing the value as string,
including the empty word.
Rename those functions to better express what they do.
Same for svSetValue*().
It is wrong to allow access to unquoted ifcfg-rh values.
All users of this ~feature~ misused it to encode meaning
in the type of quotation, which is wrong.
Also, shvar.h is not able to fully parse shell. We can improve
that, but it should be handled internally, in one place. Not by
callers applying some quirks after getting a "verbatim" value.
It is wrong to move the handling of quotes outside of shvar.h.
The ifcfg-rh core library (shvar.h) should handle quotation
transparently.
It is also wrong to encode meaning of the WPA_PSK depending on whether
the value is quoted or not. A psk that is 64 chars *must* be in hex
representation, and anything else is taken literal.
Also, the special handling of bash-syntax with $' was wrong. Including
the unit test "keys-test-wifi-wpa-psk-2" which contained invalid shell.
Support for $' must be done inside of shvar.h, for all properties alike
not just for WPA_PSK.
Let shvar.h do the escaping/unescaping of the ESSID.
We should not treat a value differently whether it is quoted or not.
Also, cutting away double quotes and calling svUnescape() is just wrong.
Now, we write a value in hex if it contains non-printable characters
or if the reader would treat it like a hex value. Reader treats ESSID
now as hex if it starts with "0x" followed by pairs of hex digits.
svUnescape() has no problem with extremely long strings.
It does not allocate any memory and has O(n) complexity.
No problem.
If somebody has a problem with extremely large files it's
shvarFile itself which caches the entire file in memory.
Also, libnm-core allows team configs to be 1 MB in size.
So, allow that here too.
It's not clear why we would read the CIPHER_GROUP/CIPHER_PAIRWISE
verbatim=TRUE (without shell unescaping). Especially since ifcfg-rh
writer does
svSetValue (ifcfg, "CIPHER_PAIRWISE", str->str, FALSE);
Depending on how arguments are passed to the called function,
this could lead to a crash.
Maybe not on 32 bit machines where the size of the pointer is
the size of an int.
Maybe not on x86_64, where the arguments are passed in registers.
Fixes: b88c309167
The tests were checking that the keyfiles had permission
0600 and there was a check-local target to prepare the permissons
of the tests.
That is inconvenient, and it is unexpected to have a check-local
target for such a case.
Also, the tests were not testing that keyfile reader would
bail out on invalid permissions. So just skip the check for
testing.
In some places we use g_file_set_contents() after a umask() to limit
the permissions of the created file. Unfortunately if the containing
directory has a default ACL the umask will be ignored and the new file
will have a mode equal to the default ACL (since g_file_set_contents()
opens the file with mode 0666).
Calling a chmod() after the file gets created is insecure (see commit
60b7ed3bdc) and so the only solution seems to be to reimplement
g_file_set_contents() and accept a mode as parameter.
We already had similar functions in the tree, consolidate them into a
new generic utility function.
https://bugzilla.gnome.org/show_bug.cgi?id=769702
Don't have the test recompile parts of the settings plugin.
Instead, build one core library that is used both by the test
and the settings plugin.
Advantage: might save some compilation time, but more importantly: the
test use the same object code then NetworkManager itself, avoiding
different behavior due to compilation flags.
