The NETLINK_TYPE_META pseudo-type is actually equivalent to an empty
nested type. Drop it and define an empty type-system instead.
This also has the nice side-effect that m->container_type_system[0] is
never NULL (which has really nasty side-effects if you try to read
attributes).
Right now we store the maximum type-ID of a type-system. This prevents us
from creating empty type-systems. Store the "count" instead, which should
be treated as max+1.
Note that type_system_union_protocol_get_type_system() currently has a
nasty hack to treat empty type-systems as invalid. This might need some
modification later on as well.
size_t is usually 64bit and int 32bit on a 64bit machine. This probably
does not matter for netlink message sizes, but nevertheless, avoid
hard-coding it anywhere.
Same as NLType, move NLTypeSystem into netlink-types.c and hide it from
the outside. Provide an accessor function for the 'max' field that is used
to allocate suitable array sizes.
Note that this will probably be removed later on, anyway. Once we support
bigger type-systems, it just seems impractical to allocate such big arrays
for each container entry. An RBTree would probably do just fine.
If we extend NLType to support arrays and further extended types, we
really want to avoid hard-coding the type-layout outside of
netlink-types.c. We already avoid accessing nl_type->type_system outside
of netlink-types.c, extend this to also avoid accessing any other fields.
Provide accessor functions for nl_type->type and nl_type->size and then
move NLType away from the type-system header.
With this in place, follow-up patches can safely turn "type_system" and
"type_system_union" into a real "union { }", and then add another type for
arrays.
Make sure we never access type->type_system or type->type_system_union
directly. This is an implementation detail of the type-system and we
should always use the accessors. Right now, they only exist for 2-level
accesses (type-system to type-system). This patch introduces the 1-level
accessors (type to type-system) and makes use of it.
This patch makes sure the proper assertions are in place, so we never
accidentally access sub-type-systems for non-nested/union types.
Note that this places hard-asserts on the accessors. This should be fine,
as we expect callers to only access sub type-systems if they *know*
they're dealing with nested types.
The NLA_ names are used to name real datatypes we extract out of netlink
messages. The kernel has an internal enum with the same names
(NLA_foobar), which is *NOT* binary compatible to our types. Furthermore,
we support a different set of types than the kernel (as we try to treat
some kernel peculiarities as our own types to simplify the API).
Rename NLA_ to NETLINK_TYPE_ to make clear that this is our own set of
types.
Commit v218-247-g11c6f69 broke the output of the utility. "%1$" PRIu64
"x" expands to "%1$lux", essentially "%lux", which shows the problem.
u and x cannot be combined, u wins as the type character, and x gets
emitted verbatim to stdout.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1227503
Similar to SmackProcessLabel=, if this configuration is set, systemd
executes processes with given SMACK label. If unit has
SmackProcessLabel=, this config is overwritten.
But, do NOT be confused with SMACK64EXEC of execute file. This default
execute process label(and also label which is set by
SmackProcessLabel=) is set fork-ed process SMACK subject label and
used to access the execute file.
If the execution file has also SMACK64EXEC, finally executed process
has SMACK64EXEC subject.
While if the execution file has no SMACK64EXEC, the executed process
has label of this config(or label which is set by
SmackProcessLabel=). Because if execution file has no SMACK64EXEC then
excuted process inherits label from caller process(in this case, the
caller is systemd).
Smack is also able to have modification rules of existing rules. In
this case, the rule has additional argument to modify previous
rule. /sys/fs/smackfs/load2 node can only take three arguments:
subject object access. So if modification rules are written to
/sys/fs/smackfs/load2, EINVAL error is happen. Those modification
rules have to be written to /sys/fs/smackfs/change-rule.
To distinguish access with operation of cipso2, split write_rules()
for each operation. And, in write access rules, parse the rule and if
the rule has four argument then write into
/sys/fs/smackfs/change-rule.
https://lwn.net/Articles/532340/
fwrite() or fputs() are fancy functions to write byte stream such like
regular file. But special files on linux such like proc, sysfs are not
stream of bytes. Those special files on linux have to be written with
specific size.
By this reason, in some of many case, fputs() was failed to write
buffer to smack load2 node.
The write operation for the smack nodes should be performed with
write().
This may be used from multi-threaded programs (say through nss-resolve),
so we must protect the global list.
This is still only relevant for debug builds, so we do not try to handle
cases where the locking fail, but simply assert.
In such a case let's suppress the warning (downgrade to LOG_DEBUG),
under the assumption that the user has no config file to update in its
place, but a symlink that points to something like resolved's
automatically managed resolve.conf file.
While we are at it, also stop complaining if we cannot write /etc/resolv.conf
due to a read-only disk, given that there's little we could do about it.
We allow to specify a callback but then ignore the result. Looks like a trivial typo.
From 7b3fd6313c4b07b6f822a9f979d0c22350a401d9#diff-f010fa21ba7b659b519c122743e55604
Correctly support cases when the EDITOR environment variable and friends
also contain arguments. For example, to run emacs in terminal only, one
can say:
EDITOR="emacs -nw" systemctl edit myservice
When pulling by image digest the identifiers that
were produced by parsing image digest were later
overwritten by code parsing image tag.
This resulted in invalid identifiers being used
when contacting the remote endpoint, resulting in 404.
Reported here:
http://lists.freedesktop.org/archives/systemd-devel/2015-June/033039.html
The test-barrier binary uses real-time alarms and timeouts to test for
races in the thread-barrier implementation. Hence, if your system is under
high load and your scheduler decides to not run test-barrier for
>BASE_TIME, then the tests are likely to fail.
Two options:
1) Increase BASE_TIME. This will make the test take significantly longer
for no real good. Furthermore, it is still not guaranteed that the
task is scheduled.
2) Don't rely on real-time timers, but use explicit synchronization. This
would basically test one barrier implementation with another.. kinda
ironic.. but maybe something worth looking into.
3) Disable test-barrier by default.
This patch chooses option 3) and makes sure test-barrier only runs if you
pass any argument.
Side note:
test-barrier is written in a way that if it fails under load, but
does not on idle systems, then it is very _unlikely_ that the
barrier implementation is the culprit. Hence, it makes little
sense to run it under load, anyway. It will not improve the test
coverage of barrier.c, but rather the coverage of the test itself.
Let's work around crappy clocks in test-journal-interleaving.c too. This
does the same as 98d2a53417 but for
test-journal-interlaving.c rather than test-journal-stream.c.
- Make string parameter const
- Don't log some OOM errors, but not others
- Don't eat up errors generated by acl_from_text()
- Make sure check for success of every single strv_push() call
David Herrmann
Daniel Mack
Jan Engelhardt
Lennart Poettering
Dimitri John Ledkov
Tom Gundersen
Kay Sievers
WaLyong Cho
Geert Jansen
Jan Alexander Steffens (heftig)
Susant Sahani
David Herrmann
Thomas Hindoe Paaboel Andersen
Jan Synacek
Pavel Odvody
Michael Olbrich
Martin Pitt