| Age | Commit message (Collapse) | Author |
|---|
|
This makes udevadm trigger mirror udevadm info, except that multiple
device names can be specified. Instructions in 60-keyboard.hwdb should
now actually work.
udevadm(8) is updated, but it could use a bit more polishing.
https://bugs.freedesktop.org/show_bug.cgi?id=82311
|
|
The idea is to unify the way that devices can be specified.
|
|
|
|
attached to incoming messages
We don't know what the activated service might want in the end, hence
enable everything current and future, just to be sure.
|
|
|
|
On the system and user busses we create it's the receiver that chooses
which metadata is attched, not the sender, hence set the requirement
mask to ANY, to allow any current of future credential bit to be
attached.
|
|
|
|
|
|
This simplifies things a bit and makes sure we free any previously set
creds component before writing in a new one.
|
|
|
|
|
|
|
|
dropped broadcast messages and proceeding
|
|
|
|
|
|
|
|
|
|
|
|
Also, properly keep track of incoming additional service names.
|
|
kernel messages
|
|
creds object
|
|
|
|
bus owner
|
|
|
|
selinux context
|
|
credential data shall be augment with data from /proc
|
|
KDBUS_ITEM_PIDS structure from KDBUS_ITEM_CREDS
Also:
- adds support for euid, suid, fsuid, egid, sgid, fsgid fields.
- makes augmentation of creds with data from /proc explicitly
controllable to give apps better control over this, given that this is
racy.
- enables augmentation for kdbus connections (previously we only did it
for dbus1). This is useful since with recent kdbus versions it is
possible for clients to control the metadata they want to send.
- changes sd_bus_query_sender_privilege() to take the euid of the client
into consideration, if known
- when we don't have permissions to read augmentation data from /proc,
don't fail, just don't add the data in
|
|
|
|
|
|
|
|
constructing message
|
|
|
|
|
|
The .service uses "/var/lib/container", not "containers".
|
|
Make sure not to run xkb-keymap validation twice if pk-queries are used.
Move it below pk-checks.
|
|
Properly forward all XKB messages. You can use XKB_LOG_VERBOSITY= to
control the amount of messages sent by XKB. We explicitly set
XKB_LOG_LEVEL to 7 you can use SYSTEMD_LOG_LEVEL to control the log-level
generically.
|
|
Use XKB_CONTEXT_NO_FLAGS instead of magic 0.
|
|
Before forwarding keyboard events, feed them into possible compose tables.
This enables Compose-key and Dead-key features.
Few notes:
* REPEAT events are never fed into compose tables. It just doesn't make
sense and is usually not wanted. Compose-sequences are usually hard to
remember and take time to type. Thus, the REPEAT event of the
Compose-key itself would often cancel the compose sequence already.
* Stop resolving symbols for UP events. Anything but keycodes is never
associated to a physical key, but is a one-time action. There is
nothing like UP events for key-symbols!
* Cancel compose-sequences on Multi-Key UP. See the inline comment. We
should make this configurable!
|
|
Add support for compose files to idev-keyboard. This requires
libxkbcommon-0.5.0, which is pretty new, but should be fine.
We don't use the compose-files, yet. Further commits will put life into
them.
|
|
In service file, if the file has some of special SMACK label in
ExecStart= and systemd has no permission for the special SMACK label
then permission error will occurred. To resolve this, systemd should
be able to set its SMACK label to something accessible of ExecStart=.
So introduce new SmackProcessLabel. If label is specified with
SmackProcessLabel= then the child systemd will set its label to
that. To successfully execute the ExecStart=, accessible label should
be specified with SmackProcessLabel=.
Additionally, by SMACK policy, if the file in ExecStart= has no
SMACK64EXEC then the executed process will have given label by
SmackProcessLabel=. But if the file has SMACK64EXEC then the
SMACK64EXEC label will be overridden.
[zj: reword man page]
|
|
A negative return code was treated as a true value.
|
|
I often want to use the awesome "./autogen.sh [cmd]" arguments, but have
to append some custom ./configure options. For now, I always had to edit
autogen.sh manually, or copy the full commands out of it and run it
myself.
As I think this is super annoying, this commit adds support for
".config.args" files in $topdir. If it exists, any content is just
appended to $args, thus to any ./configure invokation of autogen.sh.
Maybe autotools provide something similar out-of-the-box. In that case,
feel free to revert this and lemme know!
|
|
Introduce a new optional dependency on libxkbcommon for systemd-localed.
Whenever the x11 keymap settings are changed, use libxkbcommon to compile
the keymap. If the compilation fails, print a warning so users will get
notified.
On compilation failure, we still update the keymap settings for now. This
patch just introduces the xkbcommon infrastructure to have keymap
validation in place. We can later decide if/how we want to enforce this.
|
|
For plain dm-crypt devices, the behavior of cryptsetup package is to
ignore the hash algorithm when a key file is provided. It seems wrong
to ignore a hash when it is explicitly specified, but we should default
to no hash if the keyfile is specified.
https://bugs.freedesktop.org/show_bug.cgi?id=52630
|
|
If for any reason the check failed (selinux?), we would still issue
the warning. Check the return status.
|
|
This makes the calling code a bit simpler.
|
|
strv_extend returns 0 in the case of success which means that
else if (bus_track_deserialize_item(&m->deserialized_subscribed, l) == 0)
log_warning("Unknown serialization item '%s'", l);
will be printed when value is added correctly.
|
|
Also update TODO, empty environment variables in Environment= and
EnvironmentFile= options work.
|
|
The previous version was a bit too vague. It is better
to simply list all dependency types that are followed.
Previous version also made an emphasis on dependencies introduced by
configuration. But this command (or systemd) don't care about this
distinction between configured and automatically added dependencies at
all. This distinctionis removed from the main description, and an
explanatory paragraph is added to remind the user that all
dependencies are shown, no matter where they come from.
|
|
Suggested-by: Peter Mattern <matternp@arcor.de>
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025437.html
|
