closely mirrors the existing ipv4 ruleset:
table ip6 io.systemd.nat {
set masq_saddr {
type ipv6_addr
flags interval
}
map map_port_ipport {
type inet_proto . inet_service : ipv6_addr . inet_service
}
chain prerouting {
type nat hook prerouting priority dstnat + 1; policy accept;
fib daddr type local dnat ip6 addr . port to meta l4proto . th dport map @map_port_ipport
}
chain output {
type nat hook output priority -99; policy accept;
ip6 daddr != ::1 oif "lo" dnat ip6 addr . port to meta l4proto . th dport map @map_port_ipport
}
chain postrouting {
type nat hook postrouting priority srcnat + 1; policy accept;
ip6 saddr @masq_saddr masquerade
}
}
Only difference is the use of ipv6 addresses instead of ipv4 ones.
Currently has no effect: all in-tree callers pass AF_INET exclusively.
Followup patches will make nspawn expose ipv6 too and rework
IPMasquerade option to support both/v4/v6.
homectl-pkcs11.c: In function 'identity_add_pkcs11_key_data':
homectl-pkcs11.c:155:13: error: implicit declaration of function 'pkcs11_acquire_certificate' [-Werror=implicit-function-declaration]
Restores the P11KIT compile-time test that was removed in 2289a78473
("homed: move pkcs11 LUKS glue into shared code").
I don't think it is useful to warn about about environemnt variables where the user
explicitly configured some value. If they went through the effort of escaping the cc
to include it in the setting (e.g. Environment="VAR=\efoo"), and we pass this through,
there isn't anything to warn about. This also applies to 'systemctl set-environment',
where the variable name and value are passed as arguments.
The only case where the warning *might* be useful is where the user might be
surprised by the value. This occurs when importing variables from the inherited
environment, i.e. in 'systemctl import-environment'. In not convinced that this is
useful, since the user better control their shell environment anyway.
$ systemctl import-environment
Calling import-environment without a list of variable names is deprecated.
Environment variable $LESS_TERMCAP_mb contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_md contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_me contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_se contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_so contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_ue contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_us contains control characters, importing anyway.
Environment variable $ZZZ contains control characters, importing anyway.
So far, we would allow certain control characters (NL since
b4346b9a77, TAB since 6294aa76d8), but not others. Having
other control characters in environment variable *value* is expected and widely
used, for various prompts like $LESS, $LESS_TERMCAP_*, and other similar
variables. The typical environment exported by bash already contains a dozen or
so such variables, so programs need to handle them.
We handle then correctly too, for example in 'systemctl show-environment',
since 804ee07c13. But we would still disallow setting such variables
by the user, in unit file Environment= and in set-environment/import-environment
operations. This is unexpected and confusing and doesn't help with anything
because such variables are present in the environment through other means.
When printing such variables, 'show-environment' escapes all special
characters, so variables with control characters are plainly visible.
In other uses, e.g. 'cat -v' can be used in similar fashion. This would already
need to be done to suppress color codes starting with \[.
Note that we still forbid invalid utf-8 with this patch. (Control characters
are valid, since they are valid 7-bit ascii.) I'm not sure if we should do
that, but since people haven't been actually asking for invalid utf-8, and only
for control characters, and invalid utf-8 causes other issues, I think it's OK
to leave this unchanged.
Fixes#4446, https://gitlab.gnome.org/GNOME/gnome-session/-/issues/45.
I was quite confused what is happening:
$ XXX=xxx
$ systemctl --user import-environment XXX
$ systemctl --user show-environment | grep XXX
(nothing)
Obviously, 'export XXX' was missing. Without any indication why the
export is not happening, this can be hard to figure out.
Another option would be to error out. But so far we didn't, and doing
that could break some script which optimistically tries to export some
variables, if present.
We'll leave this as opt-in (i.e. a unit that must be enabled
explicitly), since this is supposed to be a debug/developer feature
primarily, and thus no be around in regular production systems.
Florian Westphal
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Luca Boccassi
Yu Watanabe
Susant Sahani