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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In order to implement this we change the bool arg_userns into an enum
UserNamespaceMode, which can take one of NO, PICK or FIXED, and replace the
arg_uid_range_pick bool with it.
This adds the new value "pick" to --private-users=. When specified a new
UID/GID range of 65536 users is automatically and randomly allocated from the
host range 0x00080000-0xDFFF0000 and used for the container. The setting
implies --private-users-chown, so that container directory is recursively
chown()ed to the newly allocated UID/GID range, if that's necessary. As an
optimization before picking a randomized UID/GID the UID of the container's
root directory is used as starting point and used if currently not used
otherwise.
To protect against using the same UID/GID range multiple times a few mechanisms
are in place:
- The first and the last UID and GID of the range are checked with getpwuid()
and getgrgid(). If an entry already exists a different range is picked. Note
that by "last" UID the user 65534 is used, as 65535 is the 16bit (uid_t) -1.
- A lock file for the range is taken in /run/systemd/nspawn-uid/. Since the
ranges are taken in a non-overlapping fashion, and always start on 64K
boundaries this allows us to maintain a single lock file for each range that
can be randomly picked. This protects nspawn from picking the same range in
two parallel instances.
- If possible the /etc/passwd lock file is taken while a new range is selected
until the container is up. This means adduser/addgroup should safely avoid
the range as long as nss-mymachines is used, since the allocated range will
then show up in the user database.
The UID/GID range nspawn picks from is compiled in and not configurable at the
moment. That should probably stay that way, since we already provide ways how
users can pick their own ranges manually if they don't like the automatic
logic.
The new --private-users=pick logic makes user namespacing pretty useful now, as
it relieves the user from managing UID/GID ranges.
This adds a new --private-userns-chown switch that may be used in combination
with --private-userns. If it is passed a recursive chmod() operation is run on
the OS tree, fixing all file owner UID/GIDs to the right ranges. This should
make user namespacing pretty workable, as the OS trees don't need to be
prepared manually anymore.
In nspawn we invoke copy_bytes() on a TTY fd. copy_file_range() returns EBADF
on a TTY and this error is considered fatal by copy_bytes() so far. Correct
that, so that nspawn's copy_bytes() operation works again.
This is a follow-up for a44202e98b.
While the function journal-remote-parse.c:get_line() enforces an assertion that source->filled <= source->size, in function journal-remote-parse.c:process_source() there is a chance that source->size will be decreased to a lower value than source->filled, when source->buf is reallocated. Therefore a check is added that ensures that source->buf is reallocated only when source->filled is smaller than target / 2.
Let's be more careful when setting up the Slice= property of transient units:
let's use manager_load_unit_prepare() instead of manager_load_unit(), so that
the load queue isn't dispatched right away, because our own transient unit is
in it, and we don#t want to have it loaded until we finished initializing it.
That way we can be sure that local users are logged out before the network is
shut down when the system goes down, so that SSH session should be ending
cleanly before the system goes down.
Fixes: #2390
This moves the O_TMPFILE handling from the coredumping code into common library
code, and generalizes it as open_tmpfile_linkable() + link_tmpfile(). The
existing open_tmpfile() function (which creates an unlinked temporary file that
cannot be linked into the fs) is renamed to open_tmpfile_unlinkable(), to make
the distinction clear. Thus, code may now choose between:
a) open_tmpfile_linkable() + link_tmpfile()
b) open_tmpfile_unlinkable()
Depending on whether they want a file that may be linked back into the fs later
on or not.
In a later commit we should probably convert fopen_temporary() to make use of
open_tmpfile_linkable().
Followup for: #3065
Before we invoke now(CLOCK_BOOTTIME), let's make sure we actually have that
clock, since now() will otherwise hit an assert.
Specifically, let's refuse CLOCK_BOOTTIME early in sd-event if the kernel
doesn't actually support it.
This is a follow-up for #3037, and specifically:
https://github.com/systemd/systemd/pull/3037#issuecomment-210199167
Previously we'd have generally useful sd-bus utilities in bust-util.h,
intermixed with code that is specifically for writing clients for PID 1,
wrapping job and unit handling. Let's split the latter out and move it into
bus-unit-util.c, to make the sources a bit short and easier to grok.
This ports over machinectl and loginctl to also use the new GetProcesses() bus
call to show the process tree of a container or login session. This is similar
to how systemctl already has been ported over in a previous commit.
This adds a new GetProcesses() bus call to the Unit object which returns an
array consisting of all PIDs, their process names, as well as their full cgroup
paths. This is then used by "systemctl status" to show the per-unit process
tree.
This has the benefit that the client-side no longer needs to access the
cgroupfs directly to show the process tree of a unit. Instead, it now uses this
new API, which means it also works if -H or -M are used correctly, as the
information from the specific host is used, and not the one from the local
system.
Fixes: #2945
Before:
$ systemctl preset getty@.service
Failed to preset unit, file /etc/systemd/system/getty.target.wants/getty@tty1.service
already exists and is a symlink to ../../../../usr/lib/systemd/system/getty@.service.
After:
$ systemctl preset getty@.service
Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service,
pointing to /usr/lib/systemd/system/getty@.service.
We don't really care where the symlink points to. For example, it might point
to /usr/lib or /etc, and systemd will always load the unit from /etc in
preference to /usr/lib. In fact, if we make a symlink like
/etc/systemd/system/multi-user.target.wants/b.service -> ../a.service, pid1
will still start b.service. The name of the symlink is the only thing that
matters, as far as systemd is concerned. For humans it's confusing when the
symlinks points to anything else than the actual unit file. At the very least,
the symlink is supposed to point to a file with the same name in some other
directory. Since we don't care where the symlink points, we can always replace
an existing symlink.
Another option I considered would be to simply leave an existing symlink in
place. That would work too, but replacing the symlink with the expected value
seems more intuitive.
Of course those considerations only apply to .wants and .requires. Symlinks
created with "link" and "alias" are a separate matter.
Fixes#3056.
When "preset" was executed for a unit without install info, we'd warn similarly
as for "enable" and "disable". But "preset" is usually called for all units,
because the preset files are provided by the distribution, and the units are under
control of individual programs, and it's reasonable to call "preset" for all units
rather then try to do it only for the ones that can be installed.
We also don't warn about missing info for "preset-all". Thus it seems reasonable
to silently ignore units w/o install info when presetting.
(In addition, when more than one unit was specified, we'd issue the warning
only if none of them had install info. But this is probably something to fix
for enable/disable too.)
Fixes#1892.
Previously:
Failed to enable unit: Invalid argument
Now:
Failed to enable unit, file /etc/systemd/system/ssh.service already exists.
It would be nice to include the unit name in the message too. I looked into
this, but it would require major surgery on the whole installation logic,
because we first create a list of things to change, and then try to apply them
in a loop. To transfer the knowledge which unit was the source of each change,
the data structures would have to be extended to carry the unit name over into
the second loop. So I'm skipping this for now.
With the current "Type=forking", systemd tries to guess the PID it
should wait on at reboot (because we have no "PIDFile="). Depending on
how wrong the guess is, we can end up hanging forever at reboot.
Asking it not to do that eliminates the problem.
If we not marking manager dirty when link is dirty then
the state file is not updated. This is a side effect of
issue 2850
setting CriticalConnection=yes
timesyncd NTP servers given by DHCP server are ignored.
