Re: [systemd-devel] [ANNOUNCE] Git development moved to github
Daniel Mack writes: On 06/02/2015 04:34 PM, Martin Pitt wrote: Merging manually is quite a bit of work, as you have to add a new remote every time, fetch that, and pull from it. But it does keep a cleaner git log history. Btw, Harald pointed me to this simple alias that makes checking out a pending pull request a one-liner: https://gist.github.com/gnarf/5406589 Hi, I saw this thread and I can't stop from advertising a tool I recently discovered for dealings with github. https://github.com/sociomantic/git-hub You can do things like: $ git hub clone -t systemd/systemd To clone and fork into my account in one go $ git hub pull list [33] cgtop: add options to format memory, IO usage in raw bytes (haraldh) https://github.com/systemd/systemd/pull/33 [32] Ensure that /run/systemd/network exists (haraldh) https://github.com/systemd/systemd/pull/32 [31] cgtop: raw output option (disable conversion to human-readable units) (haraldh) https://github.com/systemd/systemd/pull/31 [30] More cgtop enhancements (haraldh) https://github.com/systemd/systemd/pull/30 [...] $ git hub pull checkout 33 To checkout a pull request, in detached HEAD (no new remote, nor branch...) $ git hub pull rebase 33 To rebase a pull request, update it on github and close it. It is also very easy to create new issues / pull requests, or add comments directly from the command line. Abdó. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev --daemon is broken again
Tom Gundersen writes: This should now be fixed, please let me know if that is not the case. Cheers, Tom It works for me, now. Thanks! Abdó. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev --daemon is broken again
Andrei Borzenkov writes: Was not it fixed by 693d371d30fee1da58365121801445b404416ada? No. The first time it broke was due to the udev manager wanting to be used by a single process, and was fixed in 040e689654ef08c63. Then it broke again by the commit you point 693d371d30fee1da58, due to the fact that the sd-event event loop does not like to be passed across forks. This breakage still remains in git. Abdó. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev --daemon is broken again
Hi, Since the move of udev to sd-event, udevd --daemon is broken again, and breaks the initramfs on arch linux, for example. It turns out that sd_event_add_signal (in manager_listen) complains because the sd_event event loop has moved through a fork. I assume the intention in sd-event is not supporting forking daemons in favour of sd-notify... But then I'm not sure how to fix udev --daemon short of initializing the event loop after forking, and that would become racy. Abdó. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Create a new logind session from a systemd --user unit
Hi,
Then, I want to manually launch my window manager, in a new logind session for
my user, on a different tty.
I tried adding User and PAMName to my window manager unit awesome.service
...
The unit fails with message
systemd[21209]: Failed at step GROUP spawning
/home/abdo/.config/systemd/scripts/awesome.sh: Operation not permitted
Ok, more to the point.
I think initgroups in core/execute.c always needs privileges. It is always
called when User=blah is set on a service file and always fails on systemd user
instances for unprivileged users. This prevents from using PAM within a systemd
user instance, for example.
I attach a patch that makes a call to initgroups only when we ask for a
different user than the one for the running instance (when the group access list
may be different). I'm not certain whether this would break something else,
though...
Also, there is dbus policy preventing from accessing the CreateSession method
in logind1.Manager from unprivileged users. Is this intentional?
Thanks,
Abdó Roig.
From ebf7783534d3aa3e56c20dba7450fd2169f3521f Mon Sep 17 00:00:00 2001
From: Abdo Roig-Maranges abdo.r...@gmail.com
Date: Mon, 29 Jul 2013 11:40:02 +0200
Subject: [PATCH] core: call initgroups only when uid changes
initgroups always requires the CAP_SETGID capability, and fails on
unprivileged systemd instances.
---
src/core/execute.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/core/execute.c b/src/core/execute.c
index 43b571e..e539673 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -576,7 +576,7 @@ static int ask_for_confirmation(char *response, char **argv) {
return r;
}
-static int enforce_groups(const ExecContext *context, const char *username, gid_t gid) {
+static int enforce_groups(const ExecContext *context, const char *username, uid_t uid, gid_t gid) {
bool keep_groups = false;
int r;
@@ -594,8 +594,8 @@ static int enforce_groups(const ExecContext *context, const char *username, gid_
return r;
}
-/* First step, initialize groups from /etc/groups */
-if (username gid != 0) {
+/* First step, initialize groups from /etc/groups if different uid */
+if (username gid != 0 uid != getuid()) {
if (initgroups(username, gid) 0)
return -errno;
@@ -1300,7 +1300,7 @@ int exec_spawn(ExecCommand *command,
#endif
if (apply_permissions) {
-err = enforce_groups(context, username, gid);
+err = enforce_groups(context, username, uid, gid);
if (err 0) {
r = EXIT_GROUP;
goto fail_child;
--
1.8.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Create a new logind session from a systemd --user unitt
Hi, Thanks a lot for your explanations! Either use a display manager or simply update your existing session's tty to graphical temporarily, rather then placing things on a new tty. (Note that the Fedora startx script does this implicitly this way) I figured I could use a systemd unit as a sort of very thin display manager to create a second session for my own user. I'll try using the same tty, without extra sessions, then. We are working on this bit by bit. If you want this to go faster, then please work with us, and write patches for libX11 and D-Bus. Well, this is just for my home PC... I tried managing user daemons, X, etc. via systemd --user some time ago, and loved it! I'm just trying to do it in a way that will not break much as the thing evolves. I think initgroups in core/execute.c always needs privileges. It is always called when User=blah is set on a service file and always fails on systemd user instances for unprivileged users. This prevents from using PAM within a systemd user instance, for example. Not following here. initgroups() is called before dropping prvis, so it should always work. Can you elaborate? I was referring to the systemd --user instance running as user abdo via the user@.service unit. Then when I started a systemd --user unit containing User=abdo PAMName=login I got the GROUP error I reported. In this case the initgroups() is called as my unprivileged user abdo because it is the user for which the systemd --user process is running. Did I miss something? I didn't look at it very carefully, just guessed the problem and tested a solultion that happened to work. I understand I shouldn't do the PAM stuff from a systemd --user unit, but the problem with group privs I encountered in systemd --user instances may still be an issue. Abdó Roig. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Create a new logind session from a systemd --user unit
Hello, I'm happily using systemd 204 user instance to handle my desktop (xorg, awesome wm, mpd, etc.) in Arch. I started experimenting with systemd 206 trying to adapt my setup to the changes in cgroups, slices, and all that. In 206, systemd user session is started automatically by pam_systemd when I login to a tty. Then, I want to manually launch my window manager, in a new logind session for my user, on a different tty. I tried adding User and PAMName to my window manager unit awesome.service: [Unit] Description=Awesome window manager After=xorg@0.service Requisite=xorg@0.service Requires=dbus.socket [Service] User=abdo PAMName=login TTYPath=/dev/tty7 Type=simple SyslogIdentifier=awesome Environment=DISPLAY=:0 ExecStart=/home/abdo/.config/systemd/scripts/awesome.sh start KillSignal=SIGINT TimeoutSec=15 However, as soon as I start the service with systemctl --user start awesome.service The unit fails with message systemd[21209]: Failed at step GROUP spawning /home/abdo/.config/systemd/scripts/awesome.sh: Operation not permitted Running the same service from the system systemd instance (with an already running user-owned xorg), works as expected, creating a new session. I think it fails setting the group for the process, it does not even get to the PAM stuff. The user abdo is the same for which the systemd user instance is running, of course. Is this a bug in systemd or it's me missing something? Thanks! Abdó. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
