Currently, if we're copying a file, we won't copy the owner UID/GID
from the source. If we're copying a directory, we will copy the owner
UID/GID from the source. Let's give users a bit more control over this
behavior by introducing --copy-ownership= which will default to the
current behavior but allows users to explicitly enable/disable copying
of ownership.
Let's check for CAP_SYS_ADMIN instead of root for these, and make
unmounting more graceful if we can't access the backing loop device
because of permission issues. This allows mounting and unmounting images
from an unprvileged mount namespace. The actual files in the image will
end up owned by nobody:nobody because we'll be in an unprivileged user
namespace, but assuming the directory permissions are not too strict, this
still allows interacting with the image in useful ways.
These actions interact with the host. The former needs privileges to
write into the image, the latter needs privileges to write on the host.
Neither will have the privileges required if the image is attached under
a private userns, hence, don't use one.
Streaming methods which are not used as a continuous subscription but
instead only send a series of objects all end up with the same workaround
to be able to figure out when to send sd_varlink_reply() or sd_varlink_notify().
Let's generalize this in sd-varlink itself.
Let's introduce the concept of a sentinel, which is a reply that will be sent
by sd-varlink if no other reply was queued by a method callback. The sentinel
is configured with varlink_set_sentinel(). If a sentinel is configured,
sd_varlink_reply() can be used more than once in streaming methods to queue
multiple values to stream to the client. The last queued reply is not sent
until the callback finishes. When the callback finishes, the last reply is
sent without "continues: more". If no reply was queued, the sentinel is sent.
This always using only sd_varlink_reply() in such streaming methods and
leaves sd_varlink_notify() available solely for continuous subscription
streaming methods, where we never use sd_varlink_reply() and instead disconnect
when the server exits.
The line to set opterr=0 was added in the initial commit in
3d090cc6f3. But afaict, this never worked as
intended, because ':' must be the first char in optstring given to
getopt_long() for it to return ':' for a missing option value. Since
this wasn't set, getopt_long() would return '?', and the missing value
would be handled as an unknown option:
$ build/systemd-journal-upload --key
Unknown option --key.
$ build/systemd-journal-upload --asdf
Unknown option --asdf.
Let's just do the standard thing:
$ build/systemd-journal-upload --key
build/systemd-journal-upload: option '--key' requires an argument
$ build/systemd-journal-upload --asdf
build/systemd-journal-upload: unrecognized option '--asdf'
When we say '-n --iterations=N' in --help, this means that the program
can be invoked with '-n N' or '--iterations=N' or '--iterations N'.
(The short option is specified without the argument.)
Here we tried to use '-p --order=path' to mean that the program can be
invoked with '-p' or '--order=path', but that is incompatible with the
established convention.
Also, indicate that the arg to --cpu is optional.
This reverts (in spirit) "network/tuntap: deny from owning Tun/Tap interfaces",
commit 940441b44c.
Justification similar as in the previous commit. The check is only
partially connected to the intended purpose and breaks backwards compat
without a sufficient reason.
Alternative fix for #37279.
This reverts (in sprit) commit f5cdf9515a,
"udev-rules: ignore non-system user/group in OWNER=/GROUP=".
The original change was done to clean up a situation where we added a
new group, but the group could already have been used for some other
purposes, and now the some unexpected entity would own the device.
Unfortunately, this check doesn't really address the issue, since the
existing account might as well be a system account, which might be
equally bad. In addition, this change is a big compatiblity break,
causing existing rules to stop working. Since quite a lot of systems
have local configuration to assign devices to users for various
purposes, this is very noticable to users. In a way, the original change
to add a new group was the compat break, and follow-up patch to cahnge
the rule parsing evolved a small compat break into a much bigger one.
There is merit to the change though, since device nodes shouldn't be
owned by users and groups and different mechanisms should be used
instead. To avoid breaking users systems, and since the original goal
cannot be achieved by this patch, let's downgrade this to a warning
to guide users towards different solutions.
* Replace goto cleanup with block_signals_reset + CLEANUP_TMPFILE_AT
* Use RENAME_NOREPLACE to make sure we don't overwrite any ongoing request
* Reword log messages a bit
/dev/console might have no backing driver, in which case
/sys/class/tty/console/active is empty. Unlike get_kernel_consoles()
resolve_dev_console() currently proceeds with empty devnode, resulting
in setup_input() -> acquire_terminal() emitting -EISDIR as we're trying
to open /dev/. Let's catch this and report -ENXIO.
/dev/console might have no backing driver, in which case
/sys/class/tty/console/active is empty. Unlike get_kernel_consoles()
resolve_dev_console() currently proceeds with empty devnode,
resulting in setup_input() -> acquire_terminal() emitting -EISDIR
as we're trying to open /dev/. Let's catch this and report -ENXIO.
This was originally brought up by @poettering. If the process
loads stuff on demand and flushes them out after each use,
or actively monitors file changes, they can be reloaded
by merely refreshing the resources.
This allows controlling resources to be refreshed before performing
reload, with one extra benefit that in the future we can permit
"seemless reload"s, i.e. no active signaling is done to the main process
after refreshing get updated. This could come in handy for programs
that loads stuff on demand or watches changes via inotify.
Typically when entering a namespace the userns is handled last,
because we assume our process is more privileged than the userns.
However, that assumption no longer holds for user managers, which
have no privilege over initial userns and all other namespaces
are actually owned by the userns unshared first (in executor).
Hence, let's add another flavor namespace_enter_delegated() to
accommodate that use case.
Lennart Poettering
Betacentury
Daan De Meyer
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Zbigniew Jędrzejewski-Szmek
Yaping Li
Mike Yuan