IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This was premarily intended to support the LSB facility $httpd which is
only known by Fedora, and a bad idea since it lacks any real-life
usecase.
Similar, drop support for some other old Fedora-specific facilities.
Also, document the rules for introduction of new facilities, to clarify
the situation for the future.
The behaviour of the common name##_from_string conversion is surprising.
It accepts not only the strings from name##_table but also any number
that falls within the range of the table. The order of items in most of
our tables is an internal affair. It should not be visible to the user.
I know of a case where the surprising numeric conversion leads to a crash.
We will allow the direct numeric conversion only for the tables where the
mapping of strings to numeric values has an external meaning. This holds
for the following lookup tables:
- netlink_family, ioprio_class, ip_tos, sched_policy - their numeric
values are stable as they are defined by the Linux kernel interface.
- log_level, log_facility_unshifted - the well-known syslog interface.
We allow the user to use numeric values whose string names systemd does
not know. For instance, the user may want to test a new kernel featuring
a scheduling policy that did not exist when his systemd version was
released. A slightly unpleasant effect of this is that the
name##_to_string conversion cannot return pointers to constant strings
anymore. The strings have to be allocated on demand and freed by the
caller.
strtol() and friends may set EINVAL if no conversion was performed, but
they are not required to do so. In practice they don't. We need to check
for it.
https://bugzilla.redhat.com/show_bug.cgi?id=870577
This adds SMACK label configuration options to socket units.
SMACK labels should be applied to most objects on disk well before
execution time, but two items remain that are generated dynamically
at run time that require SMACK labels to be set in order to enforce
MAC on all objects.
Files on disk can be labelled using package management.
For device nodes, simple udev rules are sufficient to add SMACK labels
at boot/insertion time.
Sockets can be created at run time and systemd does just that for
several services. In order to protect FIFO's and UNIX domain sockets,
we must instruct systemd to apply SMACK labels at runtime.
This patch adds the following options:
Smack - applicable to FIFO's.
SmackIpIn/SmackIpOut - applicable to sockets.
No external dependencies are required to support SMACK, as setting
the labels is done using fsetxattr(). The labels can be set on a
kernel that does not have SMACK enabled either, so there is no need
to #ifdef any of this code out.
For more information about SMACK, please see Documentation/Smack.txt
in the kernel source code.
v3 of this patch changes the config options to be CamelCased.
Add efivarfs to the mount_table in mount-setup.c, so the EFI variable
filesystem will be mounted when systemd executed.
The EFI variable filesystem will merge in v3.7 or v3.8 linux kernel.
Cc: Kay Sievers <kay@vrfy.org>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Mantas Mikulėnas <grawity@gmail.com>
Cc: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
commit 49371bb fixed the observed division by zero, but missed another
occurrence of the same bug. It was also not the optimal fix. We can
simply make the divisor a constant by swapping it with the compared
value.
In early userspace, if kernel initialization happens extremely quickly,
a call to systemd-timestamp can potentially result in division by zero.
Ensure that the check in timespec_load, which only makes sense if tv_sec
is greater than zero, is guarded by this condition.
Starting a swap unit pointing to (What) a symlink (e.g. /dev/mapper/swap
or /dev/disk/by-uuid/...) would have said unit marked active, following
the one using the "actual" device (/dev/{dm-1,sda3}), but that new unit
would be seen as inactive.
Since all requests to stop swap units would follow/redirect to it,
and it is seen inactive, nothing would be done (swapoff never called).
This is because this unit would be treated twice in
swap_process_new_swap, the second call to swap_add_one causing it to
eventually be marked inactive.
