[systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
Hello, I've a very weird behaviour with systemd 217: # systemctl show -p Wants multi-user.target | grep network.service # systemctl show -p Wants runlevel3.target | grep network.service Wants= ... network.service ... # systemctl show -p Wants multi-user.target | grep network.service Wants=... network.service ... So basically the network.service is not part of the multi-user target dependencies. But if I'm showing the state of the runlevel3 target, the network service magically becomes a dep of multi-user.target. The network.service is an sysv service which is started by rc[345].d and has in its LSB: Provide: $network Could anybody clarify what I'm facing ? Also it appears that runlevel3 target is an alias for multi-user one. Could anybody where this alias is done ? If that's in the source code of systemd I would be curious to see where exactly. Thanks ! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mate desktop user service file
On Thu, Dec 4, 2014 at 7:06 PM, arnaud gaboury arnaud.gabo...@gmail.com wrote: On Thu, Dec 4, 2014 at 4:20 PM, arnaud gaboury arnaud.gabo...@gmail.com wrote: You seem to be using some mechanism for starting 'systemd --user' that gives it a DBUS_SESSION_BUS_ADDRESS that assumes dbus-daemon is being started via a specific third-party implementation of a dbus.service for the user bus, possibly from user-session-units. If you use the part of user-session-units that assumes a dbus-daemon will be launched, but not the part that actually launches the dbus-daemon, then I'm afraid you get to keep both pieces. Neither dbus nor systemd currently ships that dbus.service. When I suggested adding one to dbus, Lennart asked me to use a different path for the socket, then said he had no plans to support a non-kdbus user bus at all ... so that feature request is on hold. (https://bugs.freedesktop.org/show_bug.cgi?id=61301 if you're interested.) Find what is setting DBUS_SESSION_BUS_ADDRESS, and make it not do that. -- └─session-c2.scope ├─2908 login -- gabx ├─2911 -zsh ├─2929 /bin/sh /usr/bin/startx ├─2951 xinit /home/gabx/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -auth /tmp/serverauth.7yJtuNYzPM ├─2952 /usr/bin/Xorg.bin -nolisten tcp :0 vt1 -auth /tmp/serverauth.7yJtuNYzPM vt1 ├─2956 i3 ├─2979 firefox-aurora ├─2980 i3bar --bar_id=bar-0 --socket=/run/user/1000/i3/ipc-socket.2956 ├─2982 urxvt ├─2985 caja --no-desktop ├─2987 urxvt ├─2996 i3status --config=~/.config/i3/i3status.conf ├─3011 dbus-launch --autolaunch=77f348a2b3fb429b85a5de751ea9175a --binary-syntax --close-stderr --- It took me numerous tests and lots of reading the dbus literature, but I finally managed what I wanted. First, I parsed DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/dbus/user_bus_socket in my X environment (adding in ~/.xprofile). This way X11 services have a given dbus adress. Then I started my dbus user session this way : ExecStart=/usr/bin/dbus-daemon --config-file=/etc/dbus-1/session.conf (removed the --nofork --nopidfile --systemd-activation options). This leaves me with only one dbus session: 157:gabx 961 913 0 11:41 ?00:00:00 /usr/bin/dbus-daemon --config-file=/etc/dbus-1/session.conf and this output from systemd-cgls: - └─user.slice └─user-1000.slice ├─user@1000.service │ ├─913 /usr/lib/systemd/systemd --user │ ├─927 (sd-pam) │ ├─dbus.service │ │ ├─ 961 /usr/bin/dbus-daemon --config-file=/etc/dbus-1/session.conf │ │ ├─1419 /usr/lib/gvfs/gvfsd │ │ ├─1427 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes │ │ ├─1453 /usr/lib/gvfs/gvfs-udisks2-volume-monitor │ │ ├─1477 /usr/lib/at-spi2-core/at-spi-bus-launcher │ │ ├─1486 /usr/lib/gvfs/gvfs-afc-volume-monitor │ │ ├─1491 /usr/lib/gvfs/gvfsd-trash --spawner :1.1 /org/gtk/gvfs/exec_spaw/0 │ │ ├─1529 /usr/lib/GConf/gconfd-2 │ │ └─1534 /usr/lib/dconf/dconf-service │ ├─xinit.service │ │ ├─1346 /usr/bin/xinit │ │ ├─1347 /usr/bin/Xorg.bin -nolisten tcp vt1 │ │ ├─1354 i3 │ │ ├─1393 firefox-aurora │ │ ├─1394 i3bar --bar_id=bar-0 --socket=/run/user/1000/i3/ipc-socket.1354 │ │ ├─1396 caja --no-desktop │ │ ├─1398 urxvt │ │ ├─1400 urxvt │ │ ├─1403 i3status --config=~/.config/i3/i3status.conf │ │ ├─1405 zsh │ │ ├─1406 zsh │ │ ├─1546 adb -P 5037 fork-server server │ │ ├─1734 systemd-cgls │ │ └─1735 less │ ├─tmux.service │ │ ├─963 /usr/bin/tmux new-session -d -n irc irssi hangups │ │ ├─964 zsh -c irssi hangups │ │ └─968 irssi │ ├─urxvtd.service │ │ └─1276 /usr/bin/urxvtd -o -q -f │ ├─gpg-agent.service │ │ └─966 /usr/bin/gpg-agent --daemon --homedir=/home/gabx/.config/gnupg │ ├─ssh-agent.service │ │ └─958 /usr/bin/ssh-agent -d -a /run/user/1000/ssh_auth_sock │ └─mate-settings-daemon.service │ ├─1605 /usr/lib/mate-settings-daemon/mate-settings-daemon │ └─1613 /usr/bin/pulseaudio --start --log-target=syslog └─session-c1.scope ├─1296 login -- gabx └─1326 -zsh ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus-proxy: cloning smack label
When dbus client connects to systemd-bus-proxyd through
Unix domain socket proxy takes client's smack label and sets for itself.
It is done before and independent of dropping privileges.
The reason of such soluton is fact that tests of access rights
performed by lsm may take place inside kernel, not only
in userspace of recipient of message.
The bus-proxyd needs CAP_MAC_ADMIN to manipulate its label.
In case of systemd running in system mode, CAP_MAC_ADMIN
should be added to CapabilityBoundingSet in service file of bus-proxyd.
In case of systemd running in user mode ('systemd --user')
it can be achieved by addition
Capabilities=cap_mac_admin=i and SecureBits=keep-caps
to user@.service file
and setting cap_mac_admin+ei on bus-proxyd binary.
---
Makefile.am | 11 +--
configure.ac| 4
src/bus-proxyd/bus-proxyd.c | 20
src/shared/capability.c | 18 ++
src/shared/capability.h | 2 ++
units/systemd-bus-pro...@.service.in| 22 --
units/systemd-bus-pro...@.service.m4.in | 22 ++
units/u...@.service.in | 19 ---
units/u...@.service.m4.in | 23 +++
9 files changed, 98 insertions(+), 43 deletions(-)
delete mode 100644 units/systemd-bus-pro...@.service.in
create mode 100644 units/systemd-bus-pro...@.service.m4.in
delete mode 100644 units/u...@.service.in
create mode 100644 units/u...@.service.m4.in
diff --git a/Makefile.am b/Makefile.am
index 7b43733..78cf4a9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -591,7 +591,7 @@ EXTRA_DIST += \
units/systemd-f...@.service.in \
units/systemd-fsck-root.service.in \
units/systemd-machine-id-commit.service.in \
- units/u...@.service.in \
+ units/u...@.service.m4.in \
units/debug-shell.service.in \
units/systemd-suspend.service.in \
units/quotaon.service.in \
@@ -2579,9 +2579,16 @@ dist_userunit_DATA += \
endif
EXTRA_DIST += \
- units/systemd-bus-pro...@.service.in \
+ units/systemd-bus-pro...@.service.m4.in \
units/user/systemd-bus-pro...@.service.in
+if HAVE_SMACK
+bus-proxyd-set-cap-hook:
+ $(SETCAP) cap_mac_admin+ei
$(DESTDIR)$(rootlibexecdir)/systemd-bus-proxyd
+
+INSTALL_EXEC_HOOKS += bus-proxyd-set-cap-hook
+endif
+
#
--
systemd_tty_ask_password_agent_SOURCES = \
src/tty-ask-password-agent/tty-ask-password-agent.c
diff --git a/configure.ac b/configure.ac
index 356a3c3..94b4a02 100644
--- a/configure.ac
+++ b/configure.ac
@@ -90,6 +90,8 @@ AC_PATH_PROG([XSLTPROC], [xsltproc])
AC_PATH_PROG([QUOTAON], [quotaon], [/usr/sbin/quotaon],
[$PATH:/usr/sbin:/sbin])
AC_PATH_PROG([QUOTACHECK], [quotacheck], [/usr/sbin/quotacheck],
[$PATH:/usr/sbin:/sbin])
+AC_PATH_PROG([SETCAP], [setcap], [/usr/sbin/setcap], [$PATH:/usr/sbin:/sbin])
+
AC_PATH_PROG([KILL], [kill], [/usr/bin/kill], [$PATH:/usr/sbin:/sbin])
AC_PATH_PROG([KMOD], [kmod], [/usr/bin/kmod], [$PATH:/usr/sbin:/sbin])
@@ -674,6 +676,8 @@ if test x${have_smack} = xyes ; then
AC_DEFINE(HAVE_SMACK, 1, [Define if SMACK is available])
fi
+AM_CONDITIONAL([HAVE_SMACK], [test x$have_smack = xyes])
+
#
--
AC_ARG_ENABLE([gcrypt],
AS_HELP_STRING([--disable-gcrypt],[Disable optional GCRYPT support]),
diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
index 42fb0da..a9940f1 100644
--- a/src/bus-proxyd/bus-proxyd.c
+++ b/src/bus-proxyd/bus-proxyd.c
@@ -46,6 +46,7 @@
#include capability.h
#include bus-policy.h
#include bus-control.h
+#include smack-util.h
static char *arg_address = NULL;
static char *arg_command_line_buffer = NULL;
@@ -1235,6 +1236,18 @@ static int patch_sender(sd_bus *a, sd_bus_message *m) {
return 0;
}
+static int mac_smack_apply_label_and_drop_cap_mac_admin(pid_t its_pid, const
char *new_label) {
+
+int r1 = 0, r2 = 0;
+if (mac_smack_use()) {
+if (new_label its_pid)
+r1 = mac_smack_apply_pid(its_pid, new_label);
+
+r2 = drop_capability(CAP_MAC_ADMIN);
+}
+return (r1 0) ? r1 : r2;
+}
+
int main(int argc, char *argv[]) {
_cleanup_bus_close_unref_ sd_bus *a = NULL, *b = NULL;
@@ -1274,6 +1287,13 @@ int main(int argc, char *argv[]) {
if (is_unix) {
(void) getpeercred(in_fd, ucred);
(void) getpeersec(in_fd, peersec);
+
+#ifdef HAVE_SMACK
+r = mac_smack_apply_label_and_drop_cap_mac_admin(getpid(),
peersec);
+if (r 0)
+log_warning(Failed to set SMACK label (%s) and drop
+ CAP_MAC_ADMIN : %s, peersec,
Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network
On Mon, Dec 08, 2014 at 08:10:08PM +0100, Lennart Poettering wrote: Any idea when you intend to realease this new API in a release or even in a stable one? I'd like to have v2.26-rc1 this month. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] emergency, rescue and single-user
Hello, what is the difference between emergency, rescue and single-user? On F21, systemd-216-12.fc21.x86_64, they all boot into something that presents itself as Welcome to emergency mode! and they all require a root password. In case of booting into emergency.target, I can see Starting Emergency Shell in the console output. In single-user and rescue.target, I can see Starting Rescue Shell, but they all look the same. systemd.special(7) doesn't help much. Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] unit: update unit dropin paths and time when dropin file is written.
If a unit is set property by systemctl set-property, a new dropin
file is generated. But the unit's dropin_paths and dropin_mtime are
not updated. So the unit is shown as need daemon reload.
Update unit dropin_paths and dropin_mtime also when dropin file is
written.
---
src/core/unit.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/core/unit.c b/src/core/unit.c
index 43280ec..b3b0892 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -3272,7 +3272,7 @@ static int unit_drop_in_file(Unit *u,
int unit_write_drop_in(Unit *u, UnitSetPropertiesMode mode, const char *name,
const char *data) {
-_cleanup_free_ char *dir = NULL;
+_cleanup_free_ char *dir = NULL, *p = NULL, *q = NULL;
int r;
assert(u);
@@ -3284,7 +3284,24 @@ int unit_write_drop_in(Unit *u, UnitSetPropertiesMode
mode, const char *name, co
if (r 0)
return r;
-return write_drop_in(dir, u-id, 50, name, data);
+r = write_drop_in(dir, u-id, 50, name, data);
+if (r 0)
+return r;
+
+r = drop_in_file(dir, u-id, 50, name, p, q);
+if (r 0)
+return r;
+
+r = strv_extend(u-dropin_paths, q);
+if (r 0)
+return r;
+
+strv_sort(u-dropin_paths);
+strv_uniq(u-dropin_paths);
+
+u-dropin_mtime = now(CLOCK_REALTIME);
+
+return 0;
}
int unit_write_drop_in_format(Unit *u, UnitSetPropertiesMode mode, const char
*name, const char *format, ...) {
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] emergency, rescue and single-user
On Tue, Dec 9, 2014 at 2:43 PM, Jan Synáček jsyna...@redhat.com wrote: Hello, what is the difference between emergency, rescue and single-user? On F21, systemd-216-12.fc21.x86_64, they all boot into something that presents itself as Welcome to emergency mode! and they all require a root password. In case of booting into emergency.target, I can see Starting Emergency Shell in the console output. In single-user and rescue.target, I can see Starting Rescue Shell, but they all look the same. systemd.special(7) doesn't help much. rescue.target pulls in sysinit.target (mounts, swaps, udev, sysctl...), while emergency.target starts a sulogin shell and nothing more. See the graph in bootup(7). The sysv single-user mode maps directly to rescue.target. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] emergency, rescue and single-user
On Tue, 09.12.14 13:43, Jan Synáček (jsyna...@redhat.com) wrote: Hello, what is the difference between emergency, rescue and single-user? On F21, systemd-216-12.fc21.x86_64, they all boot into something that presents itself as Welcome to emergency mode! and they all require a root password. In case of booting into emergency.target, I can see Starting Emergency Shell in the console output. In single-user and rescue.target, I can see Starting Rescue Shell, but they all look the same. systemd.special(7) doesn't help much. rescue is simply how we call the old sysv single user mode. This means all early-boot services are started, but no later boot service. File systems are hence checked, udev is started, and so on. You get your shell right after sysinit.target but before basic.target basically. emergency maps to the emergency mode that sysvinit already knew: it just starts a shell, and does nothing else. No early-boot services are run. No udev, no file system checks, no nothing. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote: Hello, I've a very weird behaviour with systemd 217: # systemctl show -p Wants multi-user.target | grep network.service # systemctl show -p Wants runlevel3.target | grep network.service Wants= ... network.service ... # systemctl show -p Wants multi-user.target | grep network.service Wants=... network.service ... So basically the network.service is not part of the multi-user target dependencies. But if I'm showing the state of the runlevel3 target, the network service magically becomes a dep of multi-user.target. The network.service is an sysv service which is started by rc[345].d and has in its LSB: Provide: $network Could anybody clarify what I'm facing ? systemd lazy loads services from the file system as they are referenced. This includes symlinked aliases, which are only loaded when a unit is referenced by that specific name. Also it appears that runlevel3 target is an alias for multi-user one. Could anybody where this alias is done ? If that's in the source code of systemd I would be curious to see where exactly. The /usr/lib/systemd/system/runlevel[0-5].target symlinks create these alias names. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)
Hi. Currently notify socket is unavailable in chrooted services (again) unless you bind mount it there. Is there perhaps another, less cumbersome way? So far notify socket was: 1. abstract socket commit 8c47c7325fa1ab72febf807f8831ff24c75fbf45 notify: add minimal readiness/status protocol for spawned daemons 2. file-system socket commit 91b22f21f3824c1766d34f622c5bbb70cbe881a8 core: move abstract namespace sockets to /dev/.run Now that we have /dev/.run there's no need to use abstract namespace sockets. So, let's move things to /dev/.run, to make things more easily discoverable and improve compat with chroot() and fs namespacing. 3. abstract socket again commit 29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da manager: turn notify socket into abstract namespace socket again sd_notify() should work for daemons that chroot() as part of their initilization, hence it's a good idea to use an abstract namespace socket which is not affected by chroot. 4. file-system socket again commit 7181dbdb2e3112858d62bdaea4f0ad2ed685ccba core: move notify sockets to /run and $XDG_RUNTIME_DIR A service with PrivateNetwork= cannot access abstract namespace sockets of the host anymore, hence let's better not use abstract namespace sockets for this, since we want to make sure that PrivateNetwork= is useful and doesn't break sd_notify(). So... would it be acceptable to have two notify sockets, one abstract and one normal, the latter only set for services with PrivateNetwork or - better maybe - explicitly selectable? Any other ideas? -- K. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
Hello Lennart, Thanks for answering ! On 12/09/2014 02:10 PM, Lennart Poettering wrote: On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote: Hello, I've a very weird behaviour with systemd 217: # systemctl show -p Wants multi-user.target | grep network.service # systemctl show -p Wants runlevel3.target | grep network.service Wants= ... network.service ... # systemctl show -p Wants multi-user.target | grep network.service Wants=... network.service ... So basically the network.service is not part of the multi-user target dependencies. But if I'm showing the state of the runlevel3 target, the network service magically becomes a dep of multi-user.target. The network.service is an sysv service which is started by rc[345].d and has in its LSB: Provide: $network Could anybody clarify what I'm facing ? systemd lazy loads services from the file system as they are referenced. This includes symlinked aliases, which are only loaded when a unit is referenced by that specific name. Sorry but I don't really understand. Do you mean that the network.service wasn't loaded although the runlevel3.target, which is an alias for multi-user target (default target) wants it ? I would be glad if you could enlight me because I'm confused. Also it appears that runlevel3 target is an alias for multi-user one. Could anybody where this alias is done ? If that's in the source code of systemd I would be curious to see where exactly. The /usr/lib/systemd/system/runlevel[0-5].target symlinks create these alias names. I see now. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)
On Tue, 09.12.14 16:24, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: Hi. Currently notify socket is unavailable in chrooted services (again) unless you bind mount it there. Is there perhaps another, less cumbersome way? So far notify socket was: 1. abstract socket commit 8c47c7325fa1ab72febf807f8831ff24c75fbf45 notify: add minimal readiness/status protocol for spawned daemons 2. file-system socket commit 91b22f21f3824c1766d34f622c5bbb70cbe881a8 core: move abstract namespace sockets to /dev/.run Now that we have /dev/.run there's no need to use abstract namespace sockets. So, let's move things to /dev/.run, to make things more easily discoverable and improve compat with chroot() and fs namespacing. 3. abstract socket again commit 29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da manager: turn notify socket into abstract namespace socket again sd_notify() should work for daemons that chroot() as part of their initilization, hence it's a good idea to use an abstract namespace socket which is not affected by chroot. 4. file-system socket again commit 7181dbdb2e3112858d62bdaea4f0ad2ed685ccba core: move notify sockets to /run and $XDG_RUNTIME_DIR A service with PrivateNetwork= cannot access abstract namespace sockets of the host anymore, hence let's better not use abstract namespace sockets for this, since we want to make sure that PrivateNetwork= is useful and doesn't break sd_notify(). So... would it be acceptable to have two notify sockets, one abstract and one normal, the latter only set for services with PrivateNetwork or - better maybe - explicitly selectable? Any other ideas? Hmm, but what would you do for a service that has both PrivateNetwork and chroot enabled? I am all open for shifting things around again, but I inda would prefer a solution that works universally in the end... Ideas? I figure we could open a new mount namespace and mount the file system socket into the chroot, but not sure I like the idea... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v7] run: introduce timer support option
On Tue, 09.12.14 16:07, WaLyong Cho (walyong@samsung.com) wrote: Support timer options --on-active=, --on-boot=, --on-startup=, --on-unit-active=, --on-unit-inactive=, --on-calendar=. Each options corresponding with OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=, OnCalendar= of timer respectively. And OnCalendar= and WakeSystem= supported by --timer-property= option like --property= of systemd-run. Looks good! Applied! Thanks! And if --unit= option and timer options are specified the command can be omitted. In this case, systemd-run assumes the target service is already loaded. And just try to generate transient timer unit only. --- man/systemd-run.xml | 94 +- src/core/dbus-manager.c | 8 +- src/libsystemd/sd-bus/bus-util.c | 14 +- src/run/run.c| 628 ++- 4 files changed, 596 insertions(+), 148 deletions(-) diff --git a/man/systemd-run.xml b/man/systemd-run.xml index 28a9878..b9cec91 100644 --- a/man/systemd-run.xml +++ b/man/systemd-run.xml @@ -45,7 +45,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. refnamediv refnamesystemd-run/refname -refpurposeRun programs in transient scope or service units/refpurpose +refpurposeRun programs in transient scope or service or timer units/refpurpose /refnamediv refsynopsisdiv @@ -56,15 +56,23 @@ along with systemd; If not, see http://www.gnu.org/licenses/. arg choice=opt rep=repeatARGS/arg /arg /cmdsynopsis +cmdsynopsis + commandsystemd-run/command + arg choice=opt rep=repeatOPTIONS/arg + arg choice=opt rep=repeatTIMER OPTIONS/arg + arg choice=reqreplaceableCOMMAND/replaceable/arg + arg choice=opt rep=repeatARGS/arg +/cmdsynopsis /refsynopsisdiv refsect1 titleDescription/title -paracommandsystemd-run/command may be used to create and start -a transient filename.service/filename or a -filename.scope/filename unit and run the specified -replaceableCOMMAND/replaceable in it./para +paracommandsystemd-run/command may be used to create and +start a transient filename.service/filename or a transient +filename.timer/filename or a filename.scope/filename unit +and run the specified replaceableCOMMAND/replaceable in +it./para paraIf a command is run as transient service unit, it will be started and managed by the service manager like any other service, @@ -74,6 +82,18 @@ along with systemd; If not, see http://www.gnu.org/licenses/. will start the service asynchronously in the background and immediately return./para +paraIf a command is run with timer options, transient timer unit +also be created with transient service unit. But the transient +timer unit is only started immediately. The transient service unit +will be started when the transient timer is elapsed. If +option--unit=/option is specified with timer options, the +replaceableCOMMAND/replaceable can be omitted. In this case, +commandsystemd-run/command assumes service unit is already +loaded and creates transient timer unit only. To successfully +create timer unit, already loaded service unit should be specified +with option--unit=/option. This transient timer unit can +activate the existing service unit like any other timer./para + paraIf a command is run as transient scope unit, it will be started directly by commandsystemd-run/command and thus inherit the execution environment of the caller. It is however @@ -210,6 +230,54 @@ along with systemd; If not, see http://www.gnu.org/licenses/. xi:include href=user-system-options.xml xpointer=host / xi:include href=user-system-options.xml xpointer=machine / + varlistentry +termoption--on-active=/option/term +termoption--on-boot=/option/term +termoption--on-startup=/option/term +termoption--on-unit-active=/option/term +termoption--on-unit-inactive=/option/term + +listitemparaDefines monotonic timers relative to different +starting points. Also see varnameOnActiveSec=/varname, +varnameOnBootSec=/varname, +varnameOnStartupSec=/varname, +varnameOnUnitActiveSec=/varname and +varnameOnUnitInactiveSec=/varname in + citerefentryrefentrytitlesystemd.timer/refentrytitlemanvolnum5/manvolnum/citerefentry. This +options have no effect in conjunction with +option--scope/option./para +/listitem + /varlistentry + + varlistentry +termoption--on-calendar=/option/term + +listitemparaDefines realtime (i.e. wallclock) timers with +calendar event expressions. Also see +varnameOnCalendar=/varname in +
Re: [systemd-devel] [PATCH] unit: update unit dropin paths and time when dropin file is written.
On Tue, 09.12.14 21:46, WaLyong Cho (walyong@samsung.com) wrote: If a unit is set property by systemctl set-property, a new dropin file is generated. But the unit's dropin_paths and dropin_mtime are not updated. So the unit is shown as need daemon reload. Update unit dropin_paths and dropin_mtime also when dropin file is written. Looks good! Thanks! Applied! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus-proxy: cloning smack label
On Tue, 09.12.14 12:17, Przemyslaw Kedzierski (p.kedzier...@samsung.com) wrote:
When dbus client connects to systemd-bus-proxyd through
Unix domain socket proxy takes client's smack label and sets for itself.
It is done before and independent of dropping privileges.
The reason of such soluton is fact that tests of access rights
performed by lsm may take place inside kernel, not only
in userspace of recipient of message.
The bus-proxyd needs CAP_MAC_ADMIN to manipulate its label.
In case of systemd running in system mode, CAP_MAC_ADMIN
should be added to CapabilityBoundingSet in service file of bus-proxyd.
In case of systemd running in user mode ('systemd --user')
it can be achieved by addition
Capabilities=cap_mac_admin=i and SecureBits=keep-caps
to user@.service file
and setting cap_mac_admin+ei on bus-proxyd binary.
Looks good! Applied!
(made some minor changes though, we try to avoid strerror() nowadays,
and log_warning_errno() instead with %m)
Thanks!
---
Makefile.am | 11 +--
configure.ac| 4
src/bus-proxyd/bus-proxyd.c | 20
src/shared/capability.c | 18 ++
src/shared/capability.h | 2 ++
units/systemd-bus-pro...@.service.in| 22 --
units/systemd-bus-pro...@.service.m4.in | 22 ++
units/u...@.service.in | 19 ---
units/u...@.service.m4.in | 23 +++
9 files changed, 98 insertions(+), 43 deletions(-)
delete mode 100644 units/systemd-bus-pro...@.service.in
create mode 100644 units/systemd-bus-pro...@.service.m4.in
delete mode 100644 units/u...@.service.in
create mode 100644 units/u...@.service.m4.in
diff --git a/Makefile.am b/Makefile.am
index 7b43733..78cf4a9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -591,7 +591,7 @@ EXTRA_DIST += \
units/systemd-f...@.service.in \
units/systemd-fsck-root.service.in \
units/systemd-machine-id-commit.service.in \
- units/u...@.service.in \
+ units/u...@.service.m4.in \
units/debug-shell.service.in \
units/systemd-suspend.service.in \
units/quotaon.service.in \
@@ -2579,9 +2579,16 @@ dist_userunit_DATA += \
endif
EXTRA_DIST += \
- units/systemd-bus-pro...@.service.in \
+ units/systemd-bus-pro...@.service.m4.in \
units/user/systemd-bus-pro...@.service.in
+if HAVE_SMACK
+bus-proxyd-set-cap-hook:
+ $(SETCAP) cap_mac_admin+ei
$(DESTDIR)$(rootlibexecdir)/systemd-bus-proxyd
+
+INSTALL_EXEC_HOOKS += bus-proxyd-set-cap-hook
+endif
+
#
--
systemd_tty_ask_password_agent_SOURCES = \
src/tty-ask-password-agent/tty-ask-password-agent.c
diff --git a/configure.ac b/configure.ac
index 356a3c3..94b4a02 100644
--- a/configure.ac
+++ b/configure.ac
@@ -90,6 +90,8 @@ AC_PATH_PROG([XSLTPROC], [xsltproc])
AC_PATH_PROG([QUOTAON], [quotaon], [/usr/sbin/quotaon],
[$PATH:/usr/sbin:/sbin])
AC_PATH_PROG([QUOTACHECK], [quotacheck], [/usr/sbin/quotacheck],
[$PATH:/usr/sbin:/sbin])
+AC_PATH_PROG([SETCAP], [setcap], [/usr/sbin/setcap], [$PATH:/usr/sbin:/sbin])
+
AC_PATH_PROG([KILL], [kill], [/usr/bin/kill], [$PATH:/usr/sbin:/sbin])
AC_PATH_PROG([KMOD], [kmod], [/usr/bin/kmod], [$PATH:/usr/sbin:/sbin])
@@ -674,6 +676,8 @@ if test x${have_smack} = xyes ; then
AC_DEFINE(HAVE_SMACK, 1, [Define if SMACK is available])
fi
+AM_CONDITIONAL([HAVE_SMACK], [test x$have_smack = xyes])
+
#
--
AC_ARG_ENABLE([gcrypt],
AS_HELP_STRING([--disable-gcrypt],[Disable optional GCRYPT support]),
diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
index 42fb0da..a9940f1 100644
--- a/src/bus-proxyd/bus-proxyd.c
+++ b/src/bus-proxyd/bus-proxyd.c
@@ -46,6 +46,7 @@
#include capability.h
#include bus-policy.h
#include bus-control.h
+#include smack-util.h
static char *arg_address = NULL;
static char *arg_command_line_buffer = NULL;
@@ -1235,6 +1236,18 @@ static int patch_sender(sd_bus *a, sd_bus_message *m) {
return 0;
}
+static int mac_smack_apply_label_and_drop_cap_mac_admin(pid_t its_pid, const
char *new_label) {
+
+int r1 = 0, r2 = 0;
+if (mac_smack_use()) {
+if (new_label its_pid)
+r1 = mac_smack_apply_pid(its_pid, new_label);
+
+r2 = drop_capability(CAP_MAC_ADMIN);
+}
+return (r1 0) ? r1 : r2;
+}
+
int main(int argc, char *argv[]) {
_cleanup_bus_close_unref_ sd_bus *a = NULL, *b = NULL;
@@ -1274,6 +1287,13 @@ int main(int argc, char *argv[]) {
if (is_unix) {
(void) getpeercred(in_fd, ucred);
[systemd-devel] a way to limit restarts?
Hi, There's a routine need to support this scenario: a service runs that can fail and needs to be restarted. But if it just keeps failing it doesn't make sense to keep restarting forever, it's just overhead and the system is stuck. So in that case 1) the service needs to be left stopped in failed state, and 2) whatever failure action was specified - that action needs to be run. Ideally, need to be able to limit restarts to a number per period of time, such as 3 restarts in 10 minutes, etc. Is there a way to do this? Thanks, Alex ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] a way to limit restarts?
On Tue, Dec 9, 2014 at 7:47 PM, Nekrasov, Alexander
alexander.nekra...@emc.com wrote:
Hi,
There’s a routine need to support this scenario: a service runs that can
fail and needs to be restarted.
But if it just keeps failing it doesn’t make sense to keep restarting
forever, it’s just overhead and the system is stuck. So in that case 1) the
service needs to be left stopped in “failed” state, and 2) whatever failure
action was specified – that action needs to be run.
Ideally, need to be able to limit restarts to a number per period of time,
such as 3 restarts in 10 minutes, etc.
Sure, see StartLimit{Interval,Burst,Action}= in systemd.service(5).
--
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] a way to limit restarts?
Totally missed those. Thanks. Will OnFailure= be activated when the limit is
hit? The manual only directly describes StartLimitAction= which isn’t exactly
what’s required
From: Mantas Mikulėnas [mailto:graw...@gmail.com]
Sent: Tuesday, December 09, 2014 1:05 PM
To: Nekrasov, Alexander
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] a way to limit restarts?
On Tue, Dec 9, 2014 at 7:47 PM, Nekrasov, Alexander
alexander.nekra...@emc.commailto:alexander.nekra...@emc.com wrote:
Hi,
There’s a routine need to support this scenario: a service runs that can fail
and needs to be restarted.
But if it just keeps failing it doesn’t make sense to keep restarting forever,
it’s just overhead and the system is stuck. So in that case 1) the service
needs to be left stopped in “failed” state, and 2) whatever failure action was
specified – that action needs to be run.
Ideally, need to be able to limit restarts to a number per period of time, such
as 3 restarts in 10 minutes, etc.
Sure, see StartLimit{Interval,Burst,Action}= in systemd.service(5).
--
Mantas Mikulėnas graw...@gmail.commailto:graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting U2F over HID on Linux?
On Mon, Nov 3, 2014 at 12:41 PM, Andy Lutomirski l...@amacapital.net wrote: On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina jkos...@suse.cz wrote: On Mon, 3 Nov 2014, David Herrmann wrote: Agreed, mostly. My only real concern is that this could be annoying for the userspace developers who will need to target Linux and HIDAPI separately. Admittedly the Linux support will be trivial. I see. I'll not stop you from using hidraw, I'd just not recommend it. Especially for security stuff I dislike exposing the whole HID device writable. But yeah, I guess you got my point. Alright, I am basically thinking loudly now, but how about we allow HID drivers that would override default hidraw interface? I am very well aware of the fact that this could be opening a can of worms, so we'll have to make it very restrictive. How about, let's say, we allow HID drivers to provide custom hidraw interface (completely overriding the one that HID core would normally create) only for cases such as: - the intent is to expose only certain parts of a combined device - the intent is to introduce some level of access control I.e. still no interference of kernel with data parsing allowed. Hmm. Would this be like a filter on hidraw actions? How would udev distinguish these special hidraw devices from normal hidraw devices? Also, for U2F, this could be a little awkward. There's some crazy fragmentation stuff to allow a U2F request to be split across HID requests, and I think a kernel driver would much rather get the original unfragmented application request. I started writing a driver for this. I got enumeration working. I assume I should create a u2f device class, and then... ? Where am I supposed to get my character device from? Do I register my own chrdev major? Do I use misc? Is there some input thing I'm supposed to use? Thanks, Andy --Andy I can give the driver a try. It'll actually be simpler than the spec makes it out, since a real kernel driver will have no need to arbitrate with itself. I'll gladly review any custom HID drivers. Feel free to put me on CC when sending to linux-input. There's also a lot of examples in drivers/hid/ in case you need a head-start (especially if you need the raw_event callback). Same here, of course. Please always CC me in parallel to sending to linux-input@ to make sure that the patch doesn't fall in between cracks. Thanks, -- Jiri Kosina SUSE Labs -- Andy Lutomirski AMA Capital Management, LLC -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network
On Tue, 09.12.14 12:30, Karel Zak (k...@redhat.com) wrote: On Mon, Dec 08, 2014 at 08:10:08PM +0100, Lennart Poettering wrote: Any idea when you intend to realease this new API in a release or even in a stable one? I'd like to have v2.26-rc1 this month. Hmm, OK, then I'll release 218 with the current direct inotify hookup. We'll update this in systemd to use lbmount's native APIs as soon as that's stable (and hit Fedora...). I added TODO list items for this for systemd, so that we don't forget to do that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:
Hello Lennart,
Thanks for answering !
On 12/09/2014 02:10 PM, Lennart Poettering wrote:
On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:
Hello,
I've a very weird behaviour with systemd 217:
# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...
So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.
The network.service is an sysv service which is started by rc[345].d and
has in its LSB:
Provide: $network
Could anybody clarify what I'm facing ?
systemd lazy loads services from the file system as they are
referenced. This includes symlinked aliases, which are only loaded when
a unit is referenced by that specific name.
Sorry but I don't really understand.
Do you mean that the network.service wasn't loaded although the
runlevel3.target, which is an alias for multi-user target (default
target) wants it ?
I would be glad if you could enlight me because I'm confused.
Apparently, network.service gets pulled in only via runlevel3.target, i. e.
there is a symlink of kind
/{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service -
network.service
That is, the Wants= dependency is generated for runlevel3.target only, not for
multi-user.target.
And, because systemd loads units lazily, systemd does not know about
runlevel3.target
(and its dependencies) before anything forces systemd to load that unit.
After you issue `systemctl show runlevel3.target`, systemd loads that unit,
loads its dependencies and merges them to multi-user.target (because
runlevel3.target
is an alias for multi-user.target).
HTHs,
--
Ivan Shapovalov / intelfx /
Also it appears that runlevel3 target is an alias for multi-user one.
Could anybody where this alias is done ? If that's in the source code of
systemd I would be curious to see where exactly.
The /usr/lib/systemd/system/runlevel[0-5].target symlinks create these
alias names.
I see now.
Thanks.
signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] a way to limit restarts?
On Tuesday 09 December 2014 at 13:11:41, Nekrasov, Alexander wrote: Totally missed those. Thanks. Will OnFailure= be activated when the limit is hit? The manual only directly describes StartLimitAction= which isn’t exactly what’s required OnFailure= will be activated each time the unit enters failed state, i. e. at the same time it is restarted. There is apparently no way to start a special unit when the start limit is reached. However, I may have missed it as well... -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] emergency, rescue and single-user
Lennart Poettering lenn...@poettering.net writes: On Tue, 09.12.14 13:43, Jan Synáček (jsyna...@redhat.com) wrote: Hello, what is the difference between emergency, rescue and single-user? On F21, systemd-216-12.fc21.x86_64, they all boot into something that presents itself as Welcome to emergency mode! and they all require a root password. In case of booting into emergency.target, I can see Starting Emergency Shell in the console output. In single-user and rescue.target, I can see Starting Rescue Shell, but they all look the same. systemd.special(7) doesn't help much. rescue is simply how we call the old sysv single user mode. This means all early-boot services are started, but no later boot service. File systems are hence checked, udev is started, and so on. You get your shell right after sysinit.target but before basic.target basically. emergency maps to the emergency mode that sysvinit already knew: it just starts a shell, and does nothing else. No early-boot services are run. No udev, no file system checks, no nothing. Lennart Thanks for the explanation! -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] emergency, rescue and single-user
Mantas Mikulėnas graw...@gmail.com writes: On Tue, Dec 9, 2014 at 2:43 PM, Jan Synáček jsyna...@redhat.com wrote: Hello, what is the difference between emergency, rescue and single-user? On F21, systemd-216-12.fc21.x86_64, they all boot into something that presents itself as Welcome to emergency mode! and they all require a root password. In case of booting into emergency.target, I can see Starting Emergency Shell in the console output. In single-user and rescue.target, I can see Starting Rescue Shell, but they all look the same. systemd.special(7) doesn't help much. rescue.target pulls in sysinit.target (mounts, swaps, udev, sysctl...), while emergency.target starts a sulogin shell and nothing more. See the graph in bootup(7). Ok, good to know about bootup(7), thanks! -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v7] run: introduce timer support option
On 12/10/2014 02:25 AM, Lennart Poettering wrote: On Tue, 09.12.14 16:07, WaLyong Cho (walyong@samsung.com) wrote: Support timer options --on-active=, --on-boot=, --on-startup=, --on-unit-active=, --on-unit-inactive=, --on-calendar=. Each options corresponding with OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec=, OnCalendar= of timer respectively. And OnCalendar= and WakeSystem= supported by --timer-property= option like --property= of systemd-run. Looks good! Applied! Thanks! Do you have plan to crontab-generator? WaLyong Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] serialization bug, swap bug, etc.
On Thu, Nov 20, 2014 at 9:13 AM, Mantas Mikulėnas graw...@gmail.com wrote: ~ I'm also getting this on every reload: systemd[1]: [/usr/lib/systemd/system/systemd-journald.service:24] Failed to parse capability in bounding set, ignoring: CAP_AUDIT_READ I suppose I can ignore the message. I see that cap_audit_read was added to kernel 3.16, but unfortunately it doesn't exist in the current libcap release (libcap 2.24). Seems like this no longer shows up on my machine, since Arch seems to be building libcap against linux-api-headers now (instead of its internal copy, I guess). -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
