Re: [systemd-devel] [PATCH 03/11] Ensure that ask-password-wall starts after getty.target
Le vendredi 20 juin 2014 à 04:48 +0200, Zbigniew Jędrzejewski-Szmek a écrit : On Fri, Jun 13, 2014 at 04:41:02PM +0200, Werner Fink wrote: From: Frederic Crozat fcro...@suse.com --- units/systemd-ask-password-wall.service.in |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git units/systemd-ask-password-wall.service.in units/systemd-ask-password-wall.service.in index 0eaa274..179b010 100644 --- units/systemd-ask-password-wall.service.in +++ units/systemd-ask-password-wall.service.in @@ -8,7 +8,8 @@ [Unit] Description=Forward Password Requests to Wall Documentation=man:systemd-ask-password-console.service(8) -After=systemd-user-sessions.service +Wants=getty.target +After=systemd-user-sessions.service getty.target Why? It feels wrong to pull in getty.target from a password service. Password entry mechanisms and user login machanisms should be loosely coupled. One might e.g. use one manually configured getty to login into the system and e.g. enter passwords... Hmm, the initial patch was ensuring this service was only started after getty@tty1. From our changelog, it was later changed to the current version with : - Make sure that systemd-ask-password-wall.service has a tty as it is not sure that a tty1 exists Werner, could you elaborate ? -- Frederic Crozat Project Manager Enterprise Desktop SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Proposal] Minimal network settings passed to networkd from the kernel cmdline
On Fri, Jun 20, 2014 at 5:41 AM, Corus coroutines+syst...@gmail.com wrote: I just joined the list so I'm sorry if this is not the proper way to propose or ask for a feature to be added to systemd. I spoke in #systemd on Freenode a few days ago and I was pointed in this direction for submitting feature requests. I read this post: http://0pointer.de/blog/projects/stateless.html It sounds like systemd is working toward a boot situation where /etc is disregarded in the hopes of using default/safe values (maybe safeboot?). Basically I'd like to be able to pass minimal network settings to networkd from the kernel cmdline on an incidental basis (I don't want to supersede /etc, I just want to use this for convenience where possible): I'd like to have something like this: sysd.net=eth0:192.168.1.48/24- .256;eth1:172.16.0.3/16-0.1 I agree, we do want this. If you want to work on it, I suggest first adding support for reading the kernel's ip= option. Cheers, Tom I've already discussed this idea on IRC with others and it was negatively received -- everyone who spoke with me resisted the kernel cmdline becoming the new /etc. I want to reiterate that this is not what I am after. I want basics passed to networkd, I don't want to use the kernel cmdline for everything. Networking is pretty crucial to getting a remote box up and reachable/ssh'able. Usually I find myself having to vnc in for a console -- it can be inconvenient to maintain that gateway (imo). There are distros oriented for being minimally configured and almost reentrant. I'm thinking of TAILS or TinyCore or the slew of penetrating testing distros available out there. It would be *VERY* useful to me to boot an ISO remotely with the networking settings passed from the kernel cmdline, then ssh in and finish the configuration. I'd like to be able to do static IP assignment. I want to have the ability to use DHCP or enable responding to IPv6 router advertisements. (It'd also be useful to enable security extensions so the MAC address isn't leaked in the IPv6 assignment). It may also be useful to configure wireless interfaces by passing the encryption method and password -- though having the password visible on the kernel cmdline would not be idea. -- AGAIN, I am thinking of incidental/expendable setups -- not long-term management performed this way. I hope I've been clear, I've met a lot of resistance with this idea but I don't think it's terrible. I would simply like more discussion on its viability. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why do we must use the close_all_fds(3) function in some files?
On Tue, 17.06.14 07:59, Geunsik Lim (geunsik@gmail.com) wrote: It seems that a goal of close_all_fds() is garbage collector to guarantee available file descriptors for new fopen() system call. Nowadays, the modern computer system is multi-process/multi-thread scheme more than single-process/multi-thread. Does systemd have to care the number of open file size? Actually, Is this function need for safety net? Yes, because 1024 is the default limit per process and that is very small. Also, file descriptors are reference to resources, most importantly files but also devices, file locks, and other objects. If we keep them open, these resources stay busy, and possibly unavailable to others. For example, invain@u1204lgs:/opt/git-systemd$ ulimit -n 1024 If Systemd does not execute the close_all_fds() functions, What will be happened in real environment? Depends on the system and what you do. It's just a matter of cleanliness, and it's pretty much for free anyway as the thing basically becomes a NOP if no fd is open. On the other hand, if systemd have to not close more than two file descriptors(e.g. 5, 17, 19) for some case to release Linux distribution based on Systemd, can we use close_all_fds(except, ***)? In this case, Do we have to specify withclose_all_fds(except, 3 + 19)? I cannot parse this, sorry... I am really not sure why you want to get rid of close_all_fds()? 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] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c
On Wed, Jun 18, 2014 at 09:51:02PM +0200, Friedrich Kröner wrote: Hello, when trying systemd-networkd with =214 and the following config: [Match] Name=eth* [Network] DHCP=yes Address=2001:db8::1234:5678/64 DNS=8.8.8.8 DNS=2001:db8:1::ab9:C0A8:102 I get lots of DHCP DISCOVER events and it doesn't aquire an IPv4 address, nor sets the configured IPv6. Jun 18 18:44:31 localhost systemd[1]: Starting Network Service... Jun 18 18:44:31 localhost systemd-networkd[19468]: timestamp of '/etc/systemd/network' changed Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link 3 added Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: gained carrier Jun 18 18:44:31 localhost systemd-networkd[19468]: could not add new link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link 1 added Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : udev initialized link Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : flags change: +LOOPBACK +UP +LOWER_UP +RUNNING Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : gained carrier Jun 18 18:44:31 localhost systemd[1]: Started Network Service. Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: found matching network '/etc/systemd/network/80-dhcp.network' Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: acquiring DHCPv4 lease Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): STARTED on ifindex 3 with address 52:54:e4:d2:24:44 Jun 18 18:44:31 localhost systemd-networkd[19468]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : getting address failed: Device or resource busy Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : link state is up-to-date Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : unmanaged Jun 18 18:44:31 localhost systemd-networkd[19468]: sd-rtnl: discarding 20 bytes of incoming message Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: fe80::5054:e4ff:fed2:2444/64 Jun 18 18:44:31 localhost systemd-networkd[19468]: rtnl: received address for a nonexistent link, ignoring Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: ::1/128 Jun 18 18:44:31 localhost systemd-networkd[19468]: eth0: added address: 123.23.23.21/22 Jun 18 18:44:31 localhost systemd-networkd[19468]: lo : added address: 127.0.0.1/8 Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.45 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Jun 18 18:44:31 localhost systemd-networkd[19468]: Got message type=signal sender=org.freedesktop.DBus destination=:1.45 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a Jun 18 18:44:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:34 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:38 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:44:46 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:02 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:45:33 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:46:36 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:47:41 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER Jun 18 18:48:44 localhost systemd-networkd[19468]: DHCP CLIENT (0x3ddf8f7): DISCOVER reverting commit 63a070415db09f5b5bcc5c sd-dhcp-client: allways request broadcast restores the previous behavior. Upon restart of systemd-networkd I get the usual OFFER, REQUEST, ACK confirmation and the IPv6 gets set as well. This is on a kvm-machine with virtio_net as module. Please let me know if you want me to test anything or need further information. What DHCP server do you use? I was running networkd with 63a070415db09f5b5bcc5c included and was able to
Re: [systemd-devel] Systemd-networkd: Prepend static nameserver to DHCP-discovered nameservers
On Tue, 17.06.14 13:14, Runiq (ru...@archlinux.us) wrote: Hello all, I'm using systemd 213 on Arch Linux, and systemd-networkd/resolved with DHCP to connect to the internet. I'm also running a caching DNS server on 127.0.0.1. I'd like to make this caching server the first DNS server in the list, but I'd also like to use the nameservers discovered by systemd-resolved. Using a static resolv.conf isn't really possible, because I connect to networks with different DNS settings. I know I can set *fallback* DNS servers in /etc/systemd/resolved.conf, but is there a way with systemd-networkd to prepend my local DNS server to those discovered by DHCP? No, this is currently not supported. 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] Setting bridge parameters
On 19.06.2014 13:37, Vladimir Elisseev wrote: Hello, Simple question: is there a way to set bridge parameters (bridge forward delay, bridge hello time, etc) using systemd networking units? Regards, Vlad. Everything is here, although some props actually missing, but not related to the bridge, http://cgit.freedesktop.org/systemd/systemd/plain/src/network/networkd-netdev-gperf.gperf http://cgit.freedesktop.org/systemd/systemd/plain/src/network/networkd-network-gperf.gperf So the 'brctl' is still your fratello. :) poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting bridge parameters
On Thu, Jun 19, 2014 at 1:37 PM, Vladimir Elisseev vo...@vovan.nl wrote: Simple question: is there a way to set bridge parameters (bridge forward delay, bridge hello time, etc) using systemd networking units? This is still on the TODO. Last I heard Lukas was looking into this, so maybe we'll get that soon :) Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting bridge parameters
On 20.06.2014 13:31, Tom Gundersen wrote: On Thu, Jun 19, 2014 at 1:37 PM, Vladimir Elisseev vo...@vovan.nl wrote: Simple question: is there a way to set bridge parameters (bridge forward delay, bridge hello time, etc) using systemd networking units? This is still on the TODO. Last I heard Lukas was looking into this, so maybe we'll get that soon :) Cheers, Tom Ping. Simple question: was Lukas looking into bonding params also? :) poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: systemd.net devwork
Ping Pong. Are you all asleep!? :) poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers.d - fix typo in user definition file
On Mon, 16.06.14 17:57, Jonathan Boulle (jonathanbou...@gmail.com) wrote: sysusers.d/systemd.conf.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks! Applied! diff --git a/sysusers.d/systemd.conf.in b/sysusers.d/systemd.conf.in index b34a8071aaff..bbdc261620d8 100644 --- a/sysusers.d/systemd.conf.in +++ b/sysusers.d/systemd.conf.in @@ -8,7 +8,7 @@ # The superuser u root 0 Super User -# The nobody use for NFS file systems +# The nobody user for NFS file systems u nobody65534 Nobody # Administrator group: can *see* more than normal users ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel 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] NoNewPrivileges and Postfix
On Wed, 18.06.14 16:07, Marco d'Itri (m...@linux.it) wrote: I tried using NoNewPrivileges=yes in my inn package, but then I noticed that the daemon was unable to send emails: Jun 18 07:59:38 bongo boot[4623]: postdrop: warning: mail_queue_enter: create file maildrop/111862.4636: Permission denied This happens because postdrop is SGID to be able to securely write new emails in the incoming queue: -r-xr-sr-x 1root postdrop 13636 Mar 2 11:53 /usr/sbin/postdrop drwx-wx--T 2 postfix postdrop 4096 Jun 18 15:31 /var/spool/postfix/maildrop/ There is a different scheme with no sgid programs and a world writeable directory, but it is less secure (it allows some DoS attacks) and I see that we do not support it anymore anyway in Debian. I do not think that Postfix should use the other scheme by default, so it looks like we are stuck with not being able to enable NoNewPrivileges for daemons that (may) need to send emails. Is there any other common similar issue with NoNewPrivileges? Well, SUID and SGID binaries are used all over the place. You can use NNP only if you know you won't end up with any of those in the process subtree. In some cases this is obvious (for example: doing NNP on cron would certainly break a ton of user cronjobs), in others it is more hidden, where packagers and upstream developers need to be careful. This isn't any different from CapabilityBoundingSet= btw. 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] arch linux container filesystems
On Mon, 16.06.14 17:37, Robin Becker (ro...@reportlab.com) wrote: On 16/06/2014 14:00, Dave Reisner wrote: On Mon, Jun 16, 2014 at 01:01:31PM +0100, Robin Becker wrote: Why do I have all the file system duplicates? You don't -- df doesn't understand namespaces. You should use a tool which reads from /proc/self/mountinfo instead of /etc/mtab, e.g. findmnt. If you want df-like output from findmnt, use 'findmnt -vD'. OK thanks; pity we have to abandon old tools and learn a lot of red hat stuff. Price of progress I guess. well, findmnt is neither red hat stuff, it's used all over the distributions. And you shouldn't accept that df can't deal with mount points that reference out-of-namespace sources. File a bug against coreutils, they really should make sure they properly handle the Linux mount logic in that area. 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] arch linux container filesystems
On Mon, 16.06.14 13:01, Robin Becker (ro...@reportlab.com) wrote: I asked about this at the arch linux forum, but got no response. I run an up to date arch linux X64 system with systemd-213-9. I built a simple container using the wiki article https://wiki.archlinux.org/index.php/Systemd-nspawn after systemd-nspawn -bD ~/MyContainer and root login I see this in my df output root@MyContainer ~]# df df: '/run/user/1000': No such file or directory df: '/run/user/1000/gvfs': No such file or directory df: '/proc/kmsg (deleted)': No such file or directory df: '/proc/sys/kernel/random/boot_id (deleted)': No such file or directory Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 147418744 85779872 54127364 62% / dev 14139004 1413896 1% /dev tmpfs14139000 1413900 0% /dev/shm tmpfs14139000 1413900 0% /sys/fs/cgroup run 1413900 44 1413856 1% /run tmpfs14139000 1413900 0% /tmp tmpfs14139004 1413896 1% /dev tmpfs14139000 1413900 0% /dev/shm tmpfs1413900 44 1413856 1% /run tmpfs14139000 1413900 0% /sys/fs/cgroup tmpfs14139000 1413900 0% /tmp tmpfs 2827840282784 0% /run/user/0 [root@MyContainer ~]# Is this what is expected? Not sure why my user id (1000) is being used. Every user who logs in will nowadays get his own little /run/user/$UID tmpfs directory for runtime purposes, with a strict size limit. logind manages. Since this is a mount df will show it. I can imagine containers might not have /proc/kmsg /proc/sys/kernel/random/boot_id; is that an error in df? These files oiginate in out-of-namespace files the container itself can't see. coreutils should probably get fixed to handle this more gracefully (see other mail). Why do I have all the file system duplicates? Probably because /proc/mounts is a bit limited, and df should probably be smarter and look at /proc/self/mountinfo instead (see other mail). 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 4/9] build-sys: regenerate Makefile-man.am
On Mon, 16.06.14 20:54, Filipe Brandenburger (filbran...@google.com) wrote: This one I have fixed in a different commit already. This includes the new systemd-journald-dev-log.socket man page introduced in commit 03ee5c38cb0da and also fixes indentation of EXTRA_DIST with the fix to make-man-rules.py. --- Makefile-man.am | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Makefile-man.am b/Makefile-man.am index 03adc7ca2679..1ae058be3084 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -193,6 +193,7 @@ MANPAGES_ALIAS += \ man/systemd-hybrid-sleep.service.8 \ man/systemd-initctl.8 \ man/systemd-initctl.socket.8 \ + man/systemd-journald-dev-log.socket.8 \ man/systemd-journald.8 \ man/systemd-journald.socket.8 \ man/systemd-kexec.service.8 \ @@ -295,6 +296,7 @@ man/systemd-hibernate.service.8: man/systemd-suspend.service.8 man/systemd-hybrid-sleep.service.8: man/systemd-suspend.service.8 man/systemd-initctl.8: man/systemd-initctl.service.8 man/systemd-initctl.socket.8: man/systemd-initctl.service.8 +man/systemd-journald-dev-log.socket.8: man/systemd-journald.service.8 man/systemd-journald.8: man/systemd-journald.service.8 man/systemd-journald.socket.8: man/systemd-journald.service.8 man/systemd-kexec.service.8: man/systemd-halt.service.8 @@ -559,6 +561,9 @@ man/systemd-initctl.html: man/systemd-initctl.service.html man/systemd-initctl.socket.html: man/systemd-initctl.service.html $(html-alias) +man/systemd-journald-dev-log.socket.html: man/systemd-journald.service.html + $(html-alias) + man/systemd-journald.html: man/systemd-journald.service.html $(html-alias) @@ -1472,7 +1477,7 @@ endif # Really, do not edit this file. EXTRA_DIST += \ - man/binfmt.d.xml \ + man/binfmt.d.xml \ man/bootchart.conf.xml \ man/bootctl.xml \ man/bootup.xml \ 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 1/9] build-sys: add sysusers.d/systemd.conf to CLEANFILES
On Mon, 16.06.14 20:54, Filipe Brandenburger (filbran...@google.com) wrote: Thanks! Applied this one! The sysusers.d/systemd.conf configuration file was originally introduced in commit 1b99214789101, but it was not marked for cleanup. This caused distcheck to complain about the file not being removed by distcleam. Tested: Successfully ran make distcheck with this patchset. --- Makefile.am | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile.am b/Makefile.am index 0213c3846dca..68c579291dc0 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1820,6 +1820,9 @@ EXTRA_DIST += \ units/systemd-sysusers.service.in \ sysusers.d/systemd.conf.in +CLEANFILES += \ + sysusers.d/systemd.conf + INSTALL_DIRS += \ $(sysusersdir) endif 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 3/9] build-sys: fix indentation in make-man-rules generated output
On Mon, 16.06.14 20:54, Filipe Brandenburger (filbran...@google.com) wrote:
Applied! Thanks!
This fixes the footer where 7 spaces were used on the first line of
EXTRA_DIST,
but a Tab was clearly intended.
---
tools/make-man-rules.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/make-man-rules.py b/tools/make-man-rules.py
index 9f46f7b889c6..e75bfffba140 100644
--- a/tools/make-man-rules.py
+++ b/tools/make-man-rules.py
@@ -62,7 +62,7 @@ FOOTER = '''\
# Really, do not edit this file.
EXTRA_DIST += \\
- {files}
+ {files}
'''
def man(page, number):
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 9/9] build-sys: check that compat-libs are enabled for make dist
On Mon, 16.06.14 20:54, Filipe Brandenburger (filbran...@google.com) wrote: Running make dist requires --enable-compat-libs since DIST_SOURCES will list generated files such as libsystemd-daemon.c. This one doesn't apply without the Python stuff. Zbigniew could you have a look at the Python stuff please? And if all looks could, please also apply this patch! Thanks! Tested: $ ./configure make make dist *** compat-libs must be enabled in order to make dist make: *** [dist-check-compat-libs] Error 1 --- Makefile.am | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 87154d9f1baf..bf4840a01736 100644 --- a/Makefile.am +++ b/Makefile.am @@ -5310,7 +5310,13 @@ if !HAVE_PYTHON @false endif -dist: dist-check-python +dist-check-compat-libs: +if !ENABLE_COMPAT_LIBS + @echo *** compat-libs must be enabled in order to make dist + @false +endif + +dist: dist-check-python dist-check-compat-libs # check broken platforms limited toolchains for link breakage before we release .PHONY: linkcheck 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] next available VT for a service
On Mon, 16.06.14 17:20, Valentin Popa (valentin.p...@intel.com) wrote: Hi all, I want to start a service on the next available tty (let's call it %next_available_tty). In my case, this service handles weston-launch, but it could be any that requires a virtual terminal to run. Let's say some of the TTYs are already taken (by getty@tty1.service, etc) and I don't know which ; I would like to spawn a new user session that contains my new service on a spare tty. The service unit should look like this: [Service] ExecStart=/usr/bin/weston-launch -some_parameter StandardInput=tty StandardOutput=journal StandardError=journal TTYPath=/dev/%next_available_tty # this is hardcoded for the moment Weston must run from a virtual terminal. To launch the session, I use: https://github.com/sofar/user-session-units which checks for available seats, then creates a PAM session on tty1. Without %next_available_tty I cannot get rid of these hard-codings and I need to know which tty will be available before the system boots (reserve it). Does anyone know if such feature can be accepted in systemd. If not, maybe it can be done in another way. If yes, any pointers to start from? Hmm, wouldn't it make more sense to buil this into weston-launch? I mean, X11 has this logic, why wouldn't this be appropriate for Weston? 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] systemd not initializing
On Tue, 17.06.14 09:23, Jay D Bhatt (jay.bh...@igate.com) wrote: Hi, From the log I attached previously, I think is log statement saying as below: Starting Login Service... But then , it gets stuck at [ OK ] Reached target Login Prompts. So, I think there would be problem with systemd-login.service file for so? Can anybody point, why there is no move ahead after this statement? A couple of things: a) Please make sure to enable all kernel options listed in README. b) Make sure your kernel is new enough, see README for version requirements. c) Make sure your root image has the correct directories in place so that systemd can mount things on them. d) Read the existing documentation about how to debug things like this: http://freedesktop.org/wiki/Software/systemd/Debugging/#index1h1 Thanks 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] Slow startup of systemd-journal on BTRFS
On Wed, 18.06.14 07:51, Tollef Fog Heen (tfh...@err.no) wrote: ]] Lennart Poettering (trimming Ccs) I am invoking fallocate() in advance, because we write those files with mmap() and that of course would normally triggered SIGBUS already on the most boring of reasons, such as disk full/quota full or so. Hence, before we do anything like that, we invoke fallocate() to ensure that the space is actually available... As far as I can see, that pretty much in line with what fallocate() is supposed to be useful for, the man page says this explicitly: OOI, why not use write + read-only mmap for reading? In testing performance for another project, that's significantly faster than rw mmap. Well, non-mmap stuff might indeed be quicker, but this isn't really optimized to the last bit of speed but more to keep the code simple. And the code is quite simple now, as we can use the same codepaths to locate things for appending and for finding them... 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] [hybrid-sleep] hibernation delay
On Fri, 13.06.14 18:54, Tom Sherpen (tomsher...@mail.com) wrote: Hi, I am wondering if hybrid-sleep could support a hibernation delay, similar to what is found in pm-utils [1] Thus, you would be able to first suspend, with the machine going automatically into hibernation after a certain amount of time. Is support for such a hibernation delay planned for the future? This is currently not implemented. We could certainly add something like this to the systemd-sleep binary, however, I am not entirely sure how to do this reliably: if we do this in userspace, and first set up a timer that will resume the machine, then go to suspend, how do we figure out after resume whether we resumed because of this timer (and hence we should go to hibernation, immediately) or because of some user activity? 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] [hybrid-sleep] hibernation delay
On Fri, Jun 20, 2014 at 4:24 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 13.06.14 18:54, Tom Sherpen (tomsher...@mail.com) wrote: Hi, I am wondering if hybrid-sleep could support a hibernation delay, similar to what is found in pm-utils [1] Thus, you would be able to first suspend, with the machine going automatically into hibernation after a certain amount of time. Is support for such a hibernation delay planned for the future? This is currently not implemented. We could certainly add something like this to the systemd-sleep binary, however, I am not entirely sure how to do this reliably: if we do this in userspace, and first set up a timer that will resume the machine, then go to suspend, how do we figure out after resume whether we resumed because of this timer (and hence we should go to hibernation, immediately) or because of some user activity? I think this is usually done by comparing if the clock after wakeup == (clock before wakeup + hibernation delay + ...maybe clock drift?). [In other words, ugly hack from before s2both days.] -- 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] [hybrid-sleep] hibernation delay
Am 20.06.2014 15:24 schrieb Lennart Poettering lenn...@poettering.net: how do we figure out after resume whether we resumed because of this timer (and hence we should go to hibernation, immediately) or because of some user activity? I think there's a way to get at Linux or ACPI's information about which device triggered the wakeup (LID, RTC, whatever), but I don't remember what it was. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [hybrid-sleep] hibernation delay
On Fri, 20.06.14 15:50, Jan Alexander Steffens (jan.steff...@gmail.com) wrote: Am 20.06.2014 15:24 schrieb Lennart Poettering lenn...@poettering.net: how do we figure out after resume whether we resumed because of this timer (and hence we should go to hibernation, immediately) or because of some user activity? I think there's a way to get at Linux or ACPI's information about which device triggered the wakeup (LID, RTC, whatever), but I don't remember what it was. Well, that's not really sufficient. There can be multiple CLOCK_BOOTTIME_ALARM in place, and even if ACPI tells us that a timer caused the wakeup this wouldn't tell us which timer it was, ours, or some other timer... 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] [hybrid-sleep] hibernation delay
On Fri, 20.06.14 16:32, Mantas Mikulėnas (graw...@gmail.com) wrote: On Fri, 13.06.14 18:54, Tom Sherpen (tomsher...@mail.com) wrote: Hi, I am wondering if hybrid-sleep could support a hibernation delay, similar to what is found in pm-utils [1] Thus, you would be able to first suspend, with the machine going automatically into hibernation after a certain amount of time. Is support for such a hibernation delay planned for the future? This is currently not implemented. We could certainly add something like this to the systemd-sleep binary, however, I am not entirely sure how to do this reliably: if we do this in userspace, and first set up a timer that will resume the machine, then go to suspend, how do we figure out after resume whether we resumed because of this timer (and hence we should go to hibernation, immediately) or because of some user activity? I think this is usually done by comparing if the clock after wakeup == (clock before wakeup + hibernation delay + ...maybe clock drift?). [In other words, ugly hack from before s2both days.] So you mean that we should check if after wakeup the time is within a 5min window or so around the time we set our timer to, and if that's the case, then we assume we woke up because of this timer-hybrid-sleep thing? That sounds awfully black-magicy to me. If people happen to manually resume the machine precisely in that 5min window then the machine will immediately go to hibernation. That sounds really wrong to me. I am really not a fan of mechanisms that usually work, but sometimes don't. That's nothing I want to support. Sorry. If you can provide me with a kernel API or so that precisely tell us that one specific timerfd or so caused a resume, then I am all ears, but otherwise this is not going to happen. Sorry. If there's value in implementing something like this, then fix the kernel first, and we will make use of it. But we will not work-around lack of support from the kernel for this kind of thing. Sorry, 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] arch linux container filesystems
On 20/06/2014 12:48, Lennart Poettering wrote: well, findmnt is neither red hat stuff, it's used all over the distributions. And you shouldn't accept that df can't deal with mount points that reference out-of-namespace sources. File a bug against coreutils, they really should make sure they properly handle the Linux mount logic in that area. Lennart as a matter of fact, my manual page for findmnt lists Karel Zak k...@redhat.com as the sole author if findmnt; that others have adopted it doesn't make it not redhat stuff. You are probably right that this should be fixed in df and (presumably all the other tools that don't work properly in systemd-nspawn containers), but as a general principle I believe if you break it, you own it applies here. As a novice user of these containers, I suspect this kind of error must have been seen before by the systemd developers, so someone among the systemd contributors probably has prior discovery rights to this bug as well. In any case, some might argue that a container (lightweight or not) should be virtually indistinguishable from the original system which would mean such a bug could not happen. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] arch linux container filesystems
On Fri, 20.06.14 15:47, Robin Becker (ro...@reportlab.com) wrote: On 20/06/2014 12:48, Lennart Poettering wrote: well, findmnt is neither red hat stuff, it's used all over the distributions. And you shouldn't accept that df can't deal with mount points that reference out-of-namespace sources. File a bug against coreutils, they really should make sure they properly handle the Linux mount logic in that area. Lennart as a matter of fact, my manual page for findmnt lists Karel Zak k...@redhat.com as the sole author if findmnt; that others have adopted it doesn't make it not redhat stuff. You are probably right that this should be fixed in df and (presumably all the other tools that don't work properly in systemd-nspawn containers), but as a general principle I believe if you break it, you own it applies here. As a novice user of these containers, I suspect this kind of error must have been seen before by the systemd developers, so someone among the systemd contributors probably has prior discovery rights to this bug as well. mount namespaces and bind mounts are in no way a systemd invention. We didn't come up with this, we are not the first users. That's a kernel feature, and since a long time. You might not have noticed this before nspawn, but that's just bad luck, it could have been any other software that uses mount namespaces, like LXC, docker, ... This is in no way a systemd issue, but a general Linux issue. In any case, some might argue that a container (lightweight or not) should be virtually indistinguishable from the original system which would mean such a bug could not happen. Well, these are containers not VMs. They are actually massively different from the host. For example /sys nor /dev are virtualized, and they are unlikely to ever be. Neither is SELinux or anythign like that. Containers *are* distuingishable from normal hosts, and that's by design. And in no way systemd's design but Linux kernel stuff. You are barking up the wrong tree, we didn't introduce these concepts, you just happened to run into them for the first time playing around with systemd, but that's just bad luck. 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 05/11] After emergency service had been started any incoming traffic on syslog.socket
On Fri, 13.06.14 16:41, Werner Fink (wer...@suse.de) wrote: From: arvidj...@gmail.com will terminate emergency.service due to implicit dependencies on basic.target and therefore sysinit.target which in turn conflict with emergency.target. I am not entirely sure how emergecny.service should have been reached with syslog.socket in place? isolate should not have left it around? --- units/emergency.service.in |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git units/emergency.service.in units/emergency.service.in index 94c090f..59f7cda 100644 --- units/emergency.service.in +++ units/emergency.service.in @@ -9,7 +9,7 @@ Description=Emergency Shell Documentation=man:sulogin(8) DefaultDependencies=no -Conflicts=shutdown.target +Conflicts=shutdown.target syslog.socket Before=shutdown.target [Service] 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 07/11] Support init=/bin/bash on the kernel command line
On Mon, 16.06.14 14:51, David Herrmann (dh.herrm...@gmail.com) wrote: Hi On Mon, Jun 16, 2014 at 2:42 PM, Dr. Werner Fink wer...@suse.de wrote: On Fri, Jun 13, 2014 at 05:49:24PM +0200, Tom Gundersen wrote: On Fri, Jun 13, 2014 at 4:41 PM, Werner Fink wer...@suse.de wrote: From: Ruediger Oertel r...@suse.de Process 1 (aka init) needs to be started with an empty signal mask. That includes the process 1 that's started after the initrd is finished. When the initrd is using systemd (as it does with dracut based initrds) then it is systemd that calls the real init. Normally this is systemd again, except when the user uses for instance init=/bin/bash on the kernel command line. Why is this necessary for /bin/bash, but not for /lib/systemd/systemd? Please include the explanation in the commit message. I do not understand your question. AFAIK the signal mask is set by systemd accordingly to man:systemd.service(5) ... the only problem with this schem is that /bin/bash nor any other shell does reset its signal mask. I guess that systemd will support the init=/bin/bash on the kernel command line. IMHO this requires a clean signal mask. The question was, why is this fix related to init=/bin/bash? What does bash do different than systemd that it requires this fix? That information should be placed in the commit-message. The fix itself looks good and if you called it restore signal-mask before executing init= it'd be fine. However, calling it support init=/bin/bash implies that this is only needed for init=/bin/bash. This, however, is just a side-effect of this fix, because systemd simply doesn't care for the initial sigmask. I'll fix up the commit-msg and apply it. No need to resend. I have made another change on top now: there's no need to remember the old signal mask if we are going to die anyway. And also, we will now also reset the signal handlers, so that we don't pass any SIG_IGN handlers to the replacement process. 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 10/11] Avoid doubling the efforts for /var/log/journal
On Fri, 13.06.14 16:41, Werner Fink (wer...@suse.de) wrote:
fn = strappenda(/var/log/journal/, ids);
-(void) mkdir(fn, 0755);
+(void)mkdir(fn, 0755);
+
+/*
+ * On journaling and/or compressing file systems avoid
doubling the
+ * efforts for the system, that is set NOCOW and NOCOMP
inode flags.
+ * Check for every single flag as otherwise some of the file
systems
+ * may return EOPNOTSUPP on one unkown flag (like BtrFS
does).
+ */
+if ((fd = open(fn, O_DIRECTORY)) = 0) {
+long flags;
+if (ioctl(fd, FS_IOC_GETFLAGS, flags) == 0) {
+int old = flags;
+if (!(flagsFS_NOATIME_FL) ioctl(fd,
FS_IOC_SETFLAGS, flags|FS_NOATIME_FL) == 0)
+flags |= FS_NOATIME_FL;
+if (!(flagsFS_NOCOW_FL) ioctl(fd,
FS_IOC_SETFLAGS, flags|FS_NOCOW_FL) == 0)
+flags |= FS_NOCOW_FL;
+if (!(flagsFS_NOCOMP_FL) s-compress) {
+flags = ~FS_COMPR_FL;
+flags |= FS_NOCOMP_FL;
+}
+if (old != flags)
+ioctl(fd, FS_IOC_SETFLAGS, flags);
+}
+close(fd);
+}
Humm, no. We won't tape over problems. If the defragging thing is a
performance issue we need to figure out why that happens, and as it
stands now it simply seems to be a weakness in the current btrfs kernel
code.
But we will not work around these problems from userspace just like
that.
I mean, I am fine with giving btrfs special support and stuff, but I
want input from the right kernel guys about about this. If they
recommend this, then sure, we can do something like this, but we don't
blindly tape over this.
Sorry,
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/12] kdbus: policy tests and fixes
Hi, This series adds the test-kdbus-policy test. The first patches are prepration then you have the test. Later there are several fixes and improvments, I've performed all the tests with success. I still have another series which deals with the send access cache, will send it soon, or perhaps tomorrow it should go on top of this. Ah and there is also another series which discuss some policy design... probably next week when time permits. Please Kay, Daniel allow me this question: The policy holders are just connections that register policy entries! They dont register names, so the registered policy entry wont take any effect unless you acquire (register into database) its name ! We need here two operations: 1) register as a policy holder 2) acquire the name to be able to send to that name and to activate the policy rules. Is this the intended behaviour ? Thank you! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 02/12] test: make msg_send() return -errno
Make msg_send() return negative errno not EXIT_FAILURE. We need this
since we will add tests that fork() and drop privileges and we want all
the error codes, especially -EPERM.
After a quick grep it seems the return value of msg_send() is never
used, so it is safe to convert it, this wont break any test.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
test/kdbus-util.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/test/kdbus-util.c b/test/kdbus-util.c
index 988aa8c..b7dc057 100644
--- a/test/kdbus-util.c
+++ b/test/kdbus-util.c
@@ -189,20 +189,23 @@ int msg_send(const struct conn *conn,
strcpy(m.name, my-name-is-nice);
ret = ioctl(conn-fd, KDBUS_CMD_MEMFD_NEW, m);
if (ret 0) {
+ ret = -errno;
fprintf(stderr, KDBUS_CMD_MEMFD_NEW failed: %m\n);
- return EXIT_FAILURE;
+ return ret;
}
memfd = m.cmd.fd;
if (write(memfd, kdbus memfd 1234567, 19) != 19) {
+ ret = -errno;
fprintf(stderr, writing to memfd failed: %m\n);
- return EXIT_FAILURE;
+ return ret;
}
ret = ioctl(memfd, KDBUS_CMD_MEMFD_SEAL_SET, true);
if (ret 0) {
+ ret = -errno;
fprintf(stderr, memfd sealing failed: %m\n);
- return EXIT_FAILURE;
+ return ret;
}
size += KDBUS_ITEM_SIZE(sizeof(struct kdbus_memfd));
@@ -213,8 +216,9 @@ int msg_send(const struct conn *conn,
msg = malloc(size);
if (!msg) {
+ ret = -errno;
fprintf(stderr, unable to malloc()!?\n);
- return EXIT_FAILURE;
+ return ret;
}
memset(msg, 0, size);
@@ -269,8 +273,9 @@ int msg_send(const struct conn *conn,
ret = ioctl(conn-fd, KDBUS_CMD_MSG_SEND, msg);
if (ret 0) {
+ ret = -errno;
fprintf(stderr, error sending message: %d err %d (%m)\n, ret,
errno);
- return EXIT_FAILURE;
+ return ret;
}
if (memfd = 0)
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 03/12] test: add simple helper to drop privileges
This is needed since we will add tests to fork() + drop privileges
Signed-off-by: Djalal Harouni tix...@opendz.org
---
test/kdbus-util.c | 29 +
test/kdbus-util.h | 1 +
2 files changed, 30 insertions(+)
diff --git a/test/kdbus-util.c b/test/kdbus-util.c
index b7dc057..965c95d 100644
--- a/test/kdbus-util.c
+++ b/test/kdbus-util.c
@@ -20,6 +20,7 @@
#include errno.h
#include assert.h
#include poll.h
+#include grp.h
#include sys/ioctl.h
#include sys/mman.h
@@ -625,3 +626,31 @@ void add_match_empty(int fd)
if (ret 0)
fprintf(stderr, --- error adding conn match: %d (%m)\n, ret);
}
+
+int drop_privileges(uid_t uid, gid_t gid)
+{
+ int ret;
+
+ ret = setgroups(0, NULL);
+ if (ret 0) {
+ ret = -errno;
+ fprintf(stderr, error setgroups: %d (%m)\n, ret);
+ return ret;
+ }
+
+ ret = setresgid(gid, gid, gid);
+ if (ret 0) {
+ ret = -errno;
+ fprintf(stderr, error setresgid: %d (%m)\n, ret);
+ return ret;
+ }
+
+ ret = setresuid(uid, uid, uid);
+ if (ret 0) {
+ ret = -errno;
+ fprintf(stderr, error setresuid: %d (%m)\n, ret);
+ return ret;
+ }
+
+ return ret;
+}
diff --git a/test/kdbus-util.h b/test/kdbus-util.h
index 9771622..dd7d7b6 100644
--- a/test/kdbus-util.h
+++ b/test/kdbus-util.h
@@ -55,3 +55,4 @@ struct kdbus_item *make_policy_name(const char *name);
struct kdbus_item *make_policy_access(__u64 type, __u64 bits, __u64 id);
void add_match_empty(int fd);
+int drop_privileges(uid_t uid, gid_t gid);
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 04/12] test: add conn_update() to test KDBUS_CMD_CONN_UPDATE
Add conn_update() to perform KDBUS_CMD_CONN_UPDATE ioctl() calls.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
test/kdbus-util.c | 74 +++
test/kdbus-util.h | 4 +++
2 files changed, 78 insertions(+)
diff --git a/test/kdbus-util.c b/test/kdbus-util.c
index 965c95d..6bb3bbf 100644
--- a/test/kdbus-util.c
+++ b/test/kdbus-util.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2013 Daniel Mack
* Copyright (C) 2013 Kay Sievers
+ * Copyright (C) 2014 Djalal Harouni
*
* kdbus is free software; you can redistribute it and/or modify it under
* the terms of the GNU Lesser General Public License as published by the
@@ -606,6 +607,79 @@ int name_list(struct conn *conn, uint64_t flags)
return 0;
}
+int conn_update(struct conn *conn, const char *name,
+ const struct kdbus_policy_access *access,
+ size_t num_access, uint64_t flags)
+{
+ struct kdbus_cmd_update *update;
+ struct kdbus_item *item;
+ size_t i, size;
+ int ret;
+
+ size = sizeof(struct kdbus_cmd_update);
+ size += KDBUS_ITEM_SIZE(sizeof(uint64_t));
+ size += KDBUS_ITEM_SIZE(strlen(name) + 1);
+ size += num_access * KDBUS_ITEM_SIZE(sizeof(struct
kdbus_policy_access));
+
+ update = malloc(size);
+ if (!update) {
+ ret = -errno;
+ fprintf(stderr, error malloc: %d (%m)\n, ret);
+ return ret;
+ }
+
+ memset(update, 0, size);
+ update-size = size;
+
+ item = update-items;
+
+ /*
+* normally having flags == 0 is valid, but just keep
+* HELLO flags of __kdbus_hello(), don't check them.
+*/
+ item-type = KDBUS_ITEM_ATTACH_FLAGS;
+ item-size = KDBUS_ITEM_HEADER_SIZE + sizeof(uint64_t);
+ item-data64[0] = flags ? flags : KDBUS_ATTACH_TIMESTAMP |
+ KDBUS_ATTACH_CREDS |
+ KDBUS_ATTACH_NAMES |
+ KDBUS_ATTACH_COMM |
+ KDBUS_ATTACH_EXE |
+ KDBUS_ATTACH_CMDLINE |
+ KDBUS_ATTACH_CAPS |
+ KDBUS_ATTACH_CGROUP |
+ KDBUS_ATTACH_SECLABEL |
+ KDBUS_ATTACH_AUDIT |
+ KDBUS_ATTACH_CONN_NAME;
+ item = KDBUS_ITEM_NEXT(item);
+
+ item-type = KDBUS_ITEM_NAME;
+ item-size = KDBUS_ITEM_HEADER_SIZE + strlen(name) + 1;
+ strcpy(item-str, name);
+ item = KDBUS_ITEM_NEXT(item);
+
+ for (i = 0; i num_access; i++) {
+ item-size = KDBUS_ITEM_HEADER_SIZE +
+sizeof(struct kdbus_policy_access);
+ item-type = KDBUS_ITEM_POLICY_ACCESS;
+
+ item-policy_access.type = access[i].type;
+ item-policy_access.access = access[i].access;
+ item-policy_access.id = access[i].id;
+
+ item = KDBUS_ITEM_NEXT(item);
+ }
+
+ ret = ioctl(conn-fd, KDBUS_CMD_CONN_UPDATE, update);
+ if (ret 0) {
+ ret = -errno;
+ fprintf(stderr, error conn update: %d (%m)\n, ret);
+ }
+
+ free(update);
+
+ return ret;
+}
+
void add_match_empty(int fd)
{
struct {
diff --git a/test/kdbus-util.h b/test/kdbus-util.h
index dd7d7b6..0fcfb72 100644
--- a/test/kdbus-util.h
+++ b/test/kdbus-util.h
@@ -53,6 +53,10 @@ struct conn *kdbus_hello_activator(const char *path, const
char *name,
size_t num_access);
struct kdbus_item *make_policy_name(const char *name);
struct kdbus_item *make_policy_access(__u64 type, __u64 bits, __u64 id);
+int conn_update(struct conn *conn, const char *name,
+ const struct kdbus_policy_access *access,
+ size_t num_access, uint64_t flags);
+
void add_match_empty(int fd);
int drop_privileges(uid_t uid, gid_t gid);
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 05/12] test: add the test-kdbus-policy test
Add the test-kdbus-policy that performs:
1) Register a policy holder
2) Try to register the same name as an activator:
kdbus will break here due to a corrupted db-entries_hash
in kdbus_policy_set().
Will be fixed in the next patches.
3) Acquire the name for the policy holder
4) Create and test the connections
5) Fork and drop privileges, then create and test connections which
should be cached in the send cache after the tests.
Here we inspect the send cache and we have located several bugs,
which will be fixed in the next patches.
6) Call kdbus_set_policy_talk() to test KDBUS_CMD_CONN_UPDATE ioctl
and restrict TALK access to KDBUS_POLICY_ACCESS_USER
7) Redo test 5), now connections should all fail with -EPERM since
TALK access was restricted.
To test this we need the right capabilities to perform the setuid() and
drop privileges, so this test just check if it was exec by root.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
.gitignore | 1 +
test/Makefile| 3 +-
test/test-kdbus-policy.c | 456 +++
3 files changed, 459 insertions(+), 1 deletion(-)
create mode 100644 test/test-kdbus-policy.c
diff --git a/.gitignore b/.gitignore
index f441632..e2bdc63 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,3 +18,4 @@ test/test-kdbus-chat
test/test-kdbus-timeout
test/test-kdbus-prio
test/test-kdbus-sync
+test/test-kdbus-policy
diff --git a/test/Makefile b/test/Makefile
index 83cb736..f8117c8 100644
--- a/test/Makefile
+++ b/test/Makefile
@@ -20,7 +20,8 @@ TESTS= \
test-kdbus-chat \
test-kdbus-timeout \
test-kdbus-sync \
- test-kdbus-prio
+ test-kdbus-prio \
+ test-kdbus-policy
all: $(TESTS)
diff --git a/test/test-kdbus-policy.c b/test/test-kdbus-policy.c
new file mode 100644
index 000..6099087
--- /dev/null
+++ b/test/test-kdbus-policy.c
@@ -0,0 +1,456 @@
+/*
+ * Copyright (C) 2014 Djalal Harouni
+ *
+ * kdbus is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU Lesser General Public License as published by the
+ * Free Software Foundation; either version 2.1 of the License, or (at
+ * your option) any later version.
+ */
+
+#include stdio.h
+#include string.h
+#include fcntl.h
+#include pthread.h
+#include poll.h
+#include stdlib.h
+#include stddef.h
+#include stdint.h
+#include stdbool.h
+#include unistd.h
+#include errno.h
+#include signal.h
+#include sys/wait.h
+#include sys/prctl.h
+#include sys/ioctl.h
+
+#include kdbus-util.h
+#include kdbus-enum.h
+
+#define MAX_CONN 64
+#define POLICY_NAMEfoo.test.policy-test
+
+
+/**
+ * The purpose of these tests:
+ * 1) Check KDBUS_POLICY_TALK
+ * 2) Check the cache state: kdbus_policy_db-send_access_hash
+ * Should be extended
+ */
+
+/**
+ * Check a list of connections against conn_db[0]
+ * conn_db[0] will be the policy holder and it will set
+ * different policy accesses.
+ */
+static struct conn **conn_db;
+
+void kdbus_free_conn(struct conn *conn)
+{
+ if (conn) {
+ close(conn-fd);
+ free(conn);
+ }
+}
+
+/* Trigger kdbus_policy_set() */
+static int kdbus_set_policy_talk(struct conn *conn,
+const char *name,
+uid_t id, unsigned int type)
+{
+ struct kdbus_policy_access access = {
+ .type = type,
+ .id = id,
+ .access = KDBUS_POLICY_TALK,
+ };
+
+ return conn_update(conn, name, access, 1, 0);
+}
+
+/* The policy access will be stored in a policy holder connection */
+static int kdbus_register_activator(char *bus, const char *name,
+ struct conn **c)
+{
+ struct conn *activator;
+
+ activator = kdbus_hello_activator(bus, name, NULL, 0);
+ if (!activator)
+ return -errno;
+
+ *c = activator;
+
+ return 0;
+}
+
+static int kdbus_register_policy_holder(char *bus, const char *name,
+ struct conn **conn)
+{
+ struct conn *c;
+ struct kdbus_policy_access access[2];
+
+ access[0].type = KDBUS_POLICY_ACCESS_USER;
+ access[0].access = KDBUS_POLICY_OWN;
+ access[0].id = geteuid();
+
+ access[1].type = KDBUS_POLICY_ACCESS_WORLD;
+ access[1].access = KDBUS_POLICY_TALK;
+ access[1].id = geteuid();
+
+ c = kdbus_hello_registrar(bus, name, access, 2,
+ KDBUS_HELLO_POLICY_HOLDER);
+ if (!c)
+ return -errno;
+
+ *conn = c;
+
+ return 0;
+}
+
+static void *kdbus_recv_echo(void *ptr)
+{
+ int ret;
+ int cnt = 3;
+ struct pollfd fd;
+ struct conn *conn = ptr;
+
+ fd.fd = conn-fd;
+ fd.events = POLLIN | POLLPRI | POLLHUP;
+ fd.revents = 0;
+
+ while (cnt) {
+ cnt--;
+ ret = poll(fd, 1, 2000);
+ if (ret
[systemd-devel] [PATCH 06/12] connection: update attach_flags only if KDBUS_ITEM_ATTACH_FLAGS is provided
Fix a bug introcuded in commit d92d68414fab which fixed another bug.
conn-attach_flags should only be update if KDBUS_ITEM_ATTACH_FLAGS was
provided.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
connection.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/connection.c b/connection.c
index 3e8c5de..542f677 100644
--- a/connection.c
+++ b/connection.c
@@ -1784,6 +1784,7 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
{
const struct kdbus_item *item;
bool policy_provided = false;
+ bool flags_provided = false;
u64 attach_flags = 0;
int ret;
@@ -1795,6 +1796,7 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
switch (item-type) {
case KDBUS_ITEM_ATTACH_FLAGS:
+ flags_provided = true;
attach_flags = item-data64[0];
break;
case KDBUS_ITEM_NAME:
@@ -1807,7 +1809,8 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
if (!KDBUS_ITEMS_END(item, cmd-items, KDBUS_ITEMS_SIZE(cmd, items)))
return -EINVAL;
- conn-attach_flags = attach_flags;
+ if (flags_provided)
+ conn-attach_flags = attach_flags;
if (!policy_provided)
return 0;
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 07/12] policy: use the db-entries_hash to access the policy db entries
Use the db-entries_hash to access the policy db entries instead of the
db-send_access_hash which is just a cache for send entries.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/policy.c b/policy.c
index bf49f68..79d6fa4 100644
--- a/policy.c
+++ b/policy.c
@@ -373,7 +373,7 @@ static void __kdbus_policy_remove_owner(struct
kdbus_policy_db *db,
struct hlist_node *tmp;
int i;
- hash_for_each_safe(db-send_access_hash, i, tmp, e, hentry)
+ hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
if (e-owner == owner) {
hash_del(e-hentry);
kdbus_policy_entry_free(e);
@@ -394,7 +394,8 @@ void kdbus_policy_remove_owner(struct kdbus_policy_db *db,
}
/**
- * kdbus_policy_remove_conn() - remove all entries related to a connection
+ * kdbus_policy_remove_conn() - remove all cached entries related to
+ * a connection
* @db:The policy database
* @conn: The connection which items to remove
*/
@@ -482,7 +483,7 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
* At the same time, the lookup mechanism won't find any collisions
* when looking for already exising names.
*/
- hash_for_each_safe(db-send_access_hash, i, tmp, e, hentry)
+ hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
if (e-owner == owner) {
struct kdbus_policy_list_entry *l;
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 08/12] policy: kdbus_policy_set() make sure we restore the right entries
If kdbus_policy_set() fails we try to restore the entries that were
previously saved in a list, however due to a typo that logic was trying
to access a previously freed entry which will just break things...
So fix the typo 'l-e' instead of 'e'.
This fixes a bug triggered by test-kdbus-policy and makes the code able
to restore previously saved entries in case of errors.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/policy.c b/policy.c
index 79d6fa4..9cf7f67 100644
--- a/policy.c
+++ b/policy.c
@@ -601,7 +601,7 @@ exit:
/* restore original entries from list */
list_for_each_entry_safe(l, l_tmp, list, entry) {
- kdbus_policy_add_one(db, e);
+ kdbus_policy_add_one(db, l-e);
kfree(l);
}
}
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 09/12] policy: kdbus_policy_set() use another variable to save entries
In kdbus_policy_set() function, we use the 'e' variable to reference
each entry of the 'db-entries_hash', so at the end the variable 'e' will
for sure point to a valid one.
Next in the KDBUS_ITEMS_FOREACH() iterator and if we fail at the first
KDBUS_ITEM_VALID() test, we jmp to exit:
Which contains the following:
if (e)
kdbus_policy_entry_free(e);
Here 'e' points to a valid entry and it will be freed, so even we
restore all the other entries from that list, there will be always one
missing, the last one pointed by that 'e' variable.
To fix this, just use another 'tmp_entry' variable to reference hash
entries.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/policy.c b/policy.c
index 9cf7f67..601d2a8 100644
--- a/policy.c
+++ b/policy.c
@@ -467,6 +467,7 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
const void *owner)
{
struct kdbus_policy_db_entry *e = NULL;
+ struct kdbus_policy_db_entry *tmp_entry = NULL;
struct kdbus_policy_db_entry_access *a;
const struct kdbus_item *item;
struct hlist_node *tmp;
@@ -483,8 +484,8 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
* At the same time, the lookup mechanism won't find any collisions
* when looking for already exising names.
*/
- hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
- if (e-owner == owner) {
+ hash_for_each_safe(db-entries_hash, i, tmp, tmp_entry, hentry)
+ if (tmp_entry-owner == owner) {
struct kdbus_policy_list_entry *l;
l = kzalloc(sizeof(*l), GFP_KERNEL);
@@ -493,9 +494,9 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
goto exit;
}
- l-e = e;
+ l-e = tmp_entry;
list_add_tail(l-entry, list);
- hash_del(e-hentry);
+ hash_del(tmp_entry-hentry);
}
/* Walk the list of items and look for new policies */
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 10/12] policy: kdbus_policy_set() fix a use after free bug
If we try to register the same name twice then kdbus_policy_add_one()
will fail with -EEXIST
In kdbus_policy_set() we have two calls to kdbus_policy_add_one() if
they fail we clean things up with kdbus_policy_entry_free(), but since
we failed ret == -EEXIST ,we hit the error path where we have another:
if (e)
kdbus_policy_entry_free(e);
We have a use after free bug here, Since 'e' is freed but never set to
NULL.
To fix this we can set that 'e' to NULL after each
kdbus_policy_entry_free() call, but it is better to just clean things up
in a one place, in the error path and remove the other
kdbus_policy_entry_free() calls.
Thix fixes the bug triggered by test-kdbus-policy when we try to
register the same name twice.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/policy.c b/policy.c
index 601d2a8..d75c2ef 100644
--- a/policy.c
+++ b/policy.c
@@ -512,10 +512,8 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
if (e) {
ret = kdbus_policy_add_one(db, e);
- if (ret 0) {
- kdbus_policy_entry_free(e);
+ if (ret 0)
goto exit;
- }
}
if (max_policies ++count max_policies) {
@@ -584,11 +582,8 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
goto exit;
}
- if (e) {
+ if (e)
ret = kdbus_policy_add_one(db, e);
- if (ret 0)
- kdbus_policy_entry_free(e);
- }
exit:
if (ret 0) {
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 11/12] policy: kdbus_policy_check_own_access() returns 0 on success not true
kdbus_policy_check_own_access() returns 0 if access is granted, otherwise a negative errno. So fix this by returning 0. We did not hit this since callers were checking negative values for errors. Signed-off-by: Djalal Harouni tix...@opendz.org --- policy.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/policy.c b/policy.c index d75c2ef..58ab6a5 100644 --- a/policy.c +++ b/policy.c @@ -231,7 +231,7 @@ static int kdbus_policy_check_access(const struct kdbus_policy_db_entry *e, * @conn: The connection to check * @name: The name to check * - * Return: t0 if the connection is allowed to own the name, -EPERM otherwise + * Return: 0 if the connection is allowed to own the name, -EPERM otherwise */ int kdbus_policy_check_own_access(struct kdbus_policy_db *db, const struct kdbus_conn *conn, @@ -307,8 +307,17 @@ int kdbus_policy_check_talk_access(struct kdbus_policy_db *db, unsigned int hash = 0; int ret; + /* +* user-uid maps to a fsuid at the time of a KDBUS_CMD_HELLO +* cmd, if they equal allow the TALK access, otherwise we +* proceed and perform checks against current's cred. +* +* By using the user-uid check first we reduce the exposure to +* creds changes. Privileged processes should be careful about +* what to do with a file descriptor. +*/ if (uid_eq(conn_src-user-uid, conn_dst-user-uid)) - return true; + return 0; /* * If there was a positive match for these two connections before, -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 12/12] connection: when freeing a connection purge its cached entries
When freeing a connection remove also all the cached entries related
to this connection, otherwise if we access this cached entry through
another valid connection, we will hit memory corruption bugs.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
connection.c | 4 +++-
domain.h | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/connection.c b/connection.c
index 542f677..6566117 100644
--- a/connection.c
+++ b/connection.c
@@ -1545,8 +1545,10 @@ static void __kdbus_conn_free(struct kref *kref)
if (conn-ep-policy_db)
kdbus_policy_remove_conn(conn-ep-policy_db, conn);
- if (conn-bus-policy_db)
+ if (conn-bus-policy_db) {
+ kdbus_policy_remove_conn(conn-bus-policy_db, conn);
kdbus_policy_remove_owner(conn-bus-policy_db, conn);
+ }
kdbus_meta_free(conn-owner_meta);
kdbus_match_db_free(conn-match_db);
diff --git a/domain.h b/domain.h
index 91a7d5e..9c477db 100644
--- a/domain.h
+++ b/domain.h
@@ -71,7 +71,7 @@ struct kdbus_domain {
/**
* struct kdbus_domain_user - resource accounting for users
* @kref: Reference counter
- * @domain:Domain of the user
+ * @domain:Domain of the user
* @hentry:Entry in domain user map
* @idr: Smalles possible index number of all users
* @uid: UID of the user
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 06/11] There is no ANSI support on common 3215 consoles
On Fri, 13.06.14 16:41, Werner Fink (wer...@suse.de) wrote:
Therefore strip off the ANSI escape sequences for 3215 consoles
but support 3270 consoles if found.
Hmm, this looks messy.
Please add a global systemd PID 1 setting next to the arg_show_status
variable that controls whether color shall be enable for status
output. Then, make this configurable via the kernel cmdline, and in the
configuration file like show_status itself. That would be one patch.
And then, optionally prepare a second patch that adds support for
looking for TERM= on the kernel cmdline. If we see it there we will
initialize arg_show_status from it, and turn off color if it is set to
dumb. Also, return this value as default terminal setting for $TERM
for /dev/console, but no other devices.
That way, s390 installations may simply set TERM=dumb on the kernel
cmdline and the right thing happens, their /dev/console will get color
disabled, and any raw tty clients will get TERM=dumb set for what they
need.
+#if defined (__s390__) || defined (__s390x__)
+if (cached_on_tty) {
+const char *e = getenv(TERM);
+if (!e)
+return cached_on_tty;
+if (streq(e, dumb) || strneq(e, ibm3, 4)) {
+char *mode = NULL;
+int r = parse_env_file(/proc/cmdline,
WHITESPACE, conmode, mode, NULL);
+if (r 0 || !mode || !streq(mode, 3270))
+cached_on_tty = 0;
+}
+}
+#endif
+
+#if defined (__s390__) || defined (__s390x__)
+if (streq(tty, ttyS0)) {
+char *mode = NULL;
+int r = parse_env_file(/proc/cmdline, WHITESPACE,
conmode, mode, NULL);
+if (r 0 || !mode || !streq(mode, 3270))
+return TERM=dumb;
+if (streq(mode, 3270))
+return TERM=ibm327x;
+}
+if (streq(tty, ttyS1))
+return TERM=vt220;
+#endif
+return TERM=vt102;
Yuck. No! We won't do such messy checks. No arch-specific stuff. No
hardcoding of ttyS0 or ttyS1 or whatever other tty. Support for checking
TERM= in the kernel cmdline should be something generic.
Sorry, but we will not add any specific per-arch hacks to systemd like
this. We can fix this, but then find nice generic ways to do this, but
not this messy pile of s390 hardcoded assumption. That's not how we do
things.
Also, we are not going to add code for any specific weird terminal
settings. We will do three levels: TERM=linux for the full Linux
console, TERM=vt102 otherwise, and TERM=dumb for the crap that can't do
TERM=vt102. But we are not going to hardcode support for any other
hardware into this. This is 2014. If IBM still can't build ANSI support in
their terminals, then that's the own fault, and they will not get any
support beyond TERM=dumb and no color. We will not work-around IBM's
choices in systemd's source tree.
Sorry.
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 05/11] After emergency service had been started any incoming traffic on syslog.socket
On Fri, 20.06.14 20:51, Andrey Borzenkov (arvidj...@gmail.com) wrote: I am not entirely sure how emergecny.service should have been reached with syslog.socket in place? isolate should not have left it around? commit 80cfe9e163b1c92f917e0a5e053b148fca790677 Author: Dr. Tilmann Bubeck t.bub...@reinform.de Date: Fri May 4 10:32:47 2012 +0200 Do no isolate in case of emergency or severe problems Ah, indeed! Hmm, not sure what to do then, both goals are mutally incompatible: either we don't isolate, and then risk that running some commands will trigger the substantial amount of code. Or we isolate and then things are much harder to debug, because the system is gone... 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] new user/group population on bootup
On Sun, 15.06.14 15:16, Michael Marineau (michael.marin...@coreos.com) wrote: BTW: given that there's now at least Colin, Kay, me, and CoreOS working on getting empty /etc working, can we at least try to agree where the vendor versions of the files should be? I am kinda voting for /usr/share/etc, and this is prime bike shedding material, but we should try to get some consensus there what we are pushing for, especially regarding prospects to maybe get this into RPM, to always implicitly place a copy of the config files there... For CoreOS I've been using /usr/share/pkg for most things with the exception of some stuff in /usr/share/baselayout simply because that's the name of the basic filesystem layout package we inherited from Gentoo. Using /usr/share/etc sounds good to me and we can easily switch to that for common shared data/conf files. /usr/share/pkg should probably be preferred where possible. So the default sh-compatible copy of /etc/profile may come from /usr/share/etc but the default global bashrc should probably be in /usr/share/bash. That follows the existing pattern of /usr/share so it doesn't become a random choice where default configuration files land. That said I don't really care that much so if it is easier to make /usr/share/etc a strait-up mirror of /etc I'm not going to fuss about it. :) As a side note there is already that /usr/share/misc but perhaps best to leave that alone. So, the RPM guys wanted a full tree in /usr/share, where they can put both etc and var stuff. Kay and I are pushing for /usr/share/factory/etc and /usr/share/factory/var hence. So to make a step here we now added a logic to tmpfiles to automatically copy/symlink thing from /usr/share/factory, if you use C or L in the files but don't specify a source path. This means, simply putting this in a tmpfiles line will now do the right thing if you put your resources in /usr/share/factory: C /etc/pam.d C /etc/dbus-1 These lines will initialize /etc/pam.d and /etc/dbus-1 from /usr/share/factory/etc/pam.d and /usr/share/factory/etc/dbus-1. Hope this makes sense. 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 0/12] kdbus: policy tests and fixes
Hi Djalal, On 06/20/2014 06:49 PM, Djalal Harouni wrote: This series adds the test-kdbus-policy test. The first patches are prepration then you have the test. Later there are several fixes and improvments, I've performed all the tests with success. Very nice, thanks a lot for doing this! I'll comment on the individual patches. I still have another series which deals with the send access cache, will send it soon, or perhaps tomorrow it should go on top of this. Ok, great. Please Kay, Daniel allow me this question: The policy holders are just connections that register policy entries! They dont register names, so the registered policy entry wont take any effect unless you acquire (register into database) its name ! That's correct. The idea here is to close the gap between name acquisition and the policy being applied, and the owner of a name should not be the same instance that decides who's allowed to own it, who may talk to it or see it. Likewise, a connection can only own a name on the system bus if there's a policy rule that allows just that, and the rule has to be added beforehand by the bus owner. We need here two operations: 1) register as a policy holder 2) acquire the name to be able to send to that name and to activate the policy rules. Is this the intended behaviour ? Yes, exactly, and installing a policy is a privileged operation. We thought a lot about the design here, and I think this is a good and clean solution. Did you understand that right away? Is there anything illogical about the idea you're concerned about? We're open to suggestions. After all, the code is not yet in production :) Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting bridge parameters
On 20.06.2014 13:31, poma wrote: On 19.06.2014 13:37, Vladimir Elisseev wrote: Hello, Simple question: is there a way to set bridge parameters (bridge forward delay, bridge hello time, etc) using systemd networking units? Regards, Vlad. Everything is here, although some props actually missing, but not related to the bridge, http://cgit.freedesktop.org/systemd/systemd/plain/src/network/networkd-netdev-gperf.gperf http://cgit.freedesktop.org/systemd/systemd/plain/src/network/networkd-network-gperf.gperf So the 'brctl' is still your fratello. :) Actually they are all there, but I missed the one in the patch for manuals. FTL poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 06/12] connection: update attach_flags only if KDBUS_ITEM_ATTACH_FLAGS is provided
On 06/20/2014 06:50 PM, Djalal Harouni wrote:
Fix a bug introcuded in commit d92d68414fab which fixed another bug.
conn-attach_flags should only be update if KDBUS_ITEM_ATTACH_FLAGS was
provided.
Yes, you're right of course.
Applied, thanks!
Daniel
Signed-off-by: Djalal Harouni tix...@opendz.org
---
connection.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/connection.c b/connection.c
index 3e8c5de..542f677 100644
--- a/connection.c
+++ b/connection.c
@@ -1784,6 +1784,7 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
{
const struct kdbus_item *item;
bool policy_provided = false;
+ bool flags_provided = false;
u64 attach_flags = 0;
int ret;
@@ -1795,6 +1796,7 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
switch (item-type) {
case KDBUS_ITEM_ATTACH_FLAGS:
+ flags_provided = true;
attach_flags = item-data64[0];
break;
case KDBUS_ITEM_NAME:
@@ -1807,7 +1809,8 @@ int kdbus_cmd_conn_update(struct kdbus_conn *conn,
if (!KDBUS_ITEMS_END(item, cmd-items, KDBUS_ITEMS_SIZE(cmd, items)))
return -EINVAL;
- conn-attach_flags = attach_flags;
+ if (flags_provided)
+ conn-attach_flags = attach_flags;
if (!policy_provided)
return 0;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: systemd.net devwork
Perhaps Ding Dong! :) poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 07/12] policy: use the db-entries_hash to access the policy db entries
On 06/20/2014 06:50 PM, Djalal Harouni wrote:
Use the db-entries_hash to access the policy db entries instead of the
db-send_access_hash which is just a cache for send entries.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/policy.c b/policy.c
index bf49f68..79d6fa4 100644
--- a/policy.c
+++ b/policy.c
@@ -373,7 +373,7 @@ static void __kdbus_policy_remove_owner(struct
kdbus_policy_db *db,
struct hlist_node *tmp;
int i;
- hash_for_each_safe(db-send_access_hash, i, tmp, e, hentry)
+ hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
Hmm, we need to do both, right? If an owner goes away, we need to kill
both the entries it created *and* the cached entries it is related to.
Now that I look at the code, I see that we miss an owner assignment for
the cache entries. I can fix that up later.
@@ -482,7 +483,7 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
* At the same time, the lookup mechanism won't find any collisions
* when looking for already exising names.
*/
- hash_for_each_safe(db-send_access_hash, i, tmp, e, hentry)
+ hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
if (e-owner == owner) {
struct kdbus_policy_list_entry *l;
This change looks right though.
Daniel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 08/12] policy: kdbus_policy_set() make sure we restore the right entries
On 06/20/2014 06:50 PM, Djalal Harouni wrote:
If kdbus_policy_set() fails we try to restore the entries that were
previously saved in a list, however due to a typo that logic was trying
to access a previously freed entry which will just break things...
So fix the typo 'l-e' instead of 'e'.
This fixes a bug triggered by test-kdbus-policy and makes the code able
to restore previously saved entries in case of errors.
Applied, thanks!
Daniel
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/policy.c b/policy.c
index 79d6fa4..9cf7f67 100644
--- a/policy.c
+++ b/policy.c
@@ -601,7 +601,7 @@ exit:
/* restore original entries from list */
list_for_each_entry_safe(l, l_tmp, list, entry) {
- kdbus_policy_add_one(db, e);
+ kdbus_policy_add_one(db, l-e);
kfree(l);
}
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 10/12] policy: kdbus_policy_set() fix a use after free bug
On 06/20/2014 06:50 PM, Djalal Harouni wrote:
If we try to register the same name twice then kdbus_policy_add_one()
will fail with -EEXIST
In kdbus_policy_set() we have two calls to kdbus_policy_add_one() if
they fail we clean things up with kdbus_policy_entry_free(), but since
we failed ret == -EEXIST ,we hit the error path where we have another:
if (e)
kdbus_policy_entry_free(e);
We have a use after free bug here, Since 'e' is freed but never set to
NULL.
Applied, thanks.
Daniel
To fix this we can set that 'e' to NULL after each
kdbus_policy_entry_free() call, but it is better to just clean things up
in a one place, in the error path and remove the other
kdbus_policy_entry_free() calls.
Thix fixes the bug triggered by test-kdbus-policy when we try to
register the same name twice.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/policy.c b/policy.c
index 601d2a8..d75c2ef 100644
--- a/policy.c
+++ b/policy.c
@@ -512,10 +512,8 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
if (e) {
ret = kdbus_policy_add_one(db, e);
- if (ret 0) {
- kdbus_policy_entry_free(e);
+ if (ret 0)
goto exit;
- }
}
if (max_policies ++count max_policies) {
@@ -584,11 +582,8 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
goto exit;
}
- if (e) {
+ if (e)
ret = kdbus_policy_add_one(db, e);
- if (ret 0)
- kdbus_policy_entry_free(e);
- }
exit:
if (ret 0) {
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 11/12] policy: kdbus_policy_check_own_access() returns 0 on success not true
On 06/20/2014 06:50 PM, Djalal Harouni wrote: kdbus_policy_check_own_access() returns 0 if access is granted, otherwise a negative errno. So fix this by returning 0. We did not hit this since callers were checking negative values for errors. Applied, thanks. Daniel Signed-off-by: Djalal Harouni tix...@opendz.org --- policy.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/policy.c b/policy.c index d75c2ef..58ab6a5 100644 --- a/policy.c +++ b/policy.c @@ -231,7 +231,7 @@ static int kdbus_policy_check_access(const struct kdbus_policy_db_entry *e, * @conn:The connection to check * @name:The name to check * - * Return: t0 if the connection is allowed to own the name, -EPERM otherwise + * Return: 0 if the connection is allowed to own the name, -EPERM otherwise */ int kdbus_policy_check_own_access(struct kdbus_policy_db *db, const struct kdbus_conn *conn, @@ -307,8 +307,17 @@ int kdbus_policy_check_talk_access(struct kdbus_policy_db *db, unsigned int hash = 0; int ret; + /* + * user-uid maps to a fsuid at the time of a KDBUS_CMD_HELLO + * cmd, if they equal allow the TALK access, otherwise we + * proceed and perform checks against current's cred. + * + * By using the user-uid check first we reduce the exposure to + * creds changes. Privileged processes should be careful about + * what to do with a file descriptor. + */ if (uid_eq(conn_src-user-uid, conn_dst-user-uid)) - return true; + return 0; /* * If there was a positive match for these two connections before, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 12/12] connection: when freeing a connection purge its cached entries
On 06/20/2014 06:50 PM, Djalal Harouni wrote:
When freeing a connection remove also all the cached entries related
to this connection, otherwise if we access this cached entry through
another valid connection, we will hit memory corruption bugs.
Applied, thanks.
Daniel
Signed-off-by: Djalal Harouni tix...@opendz.org
---
connection.c | 4 +++-
domain.h | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/connection.c b/connection.c
index 542f677..6566117 100644
--- a/connection.c
+++ b/connection.c
@@ -1545,8 +1545,10 @@ static void __kdbus_conn_free(struct kref *kref)
if (conn-ep-policy_db)
kdbus_policy_remove_conn(conn-ep-policy_db, conn);
- if (conn-bus-policy_db)
+ if (conn-bus-policy_db) {
+ kdbus_policy_remove_conn(conn-bus-policy_db, conn);
kdbus_policy_remove_owner(conn-bus-policy_db, conn);
+ }
kdbus_meta_free(conn-owner_meta);
kdbus_match_db_free(conn-match_db);
diff --git a/domain.h b/domain.h
index 91a7d5e..9c477db 100644
--- a/domain.h
+++ b/domain.h
@@ -71,7 +71,7 @@ struct kdbus_domain {
/**
* struct kdbus_domain_user - resource accounting for users
* @kref:Reference counter
- * @domain: Domain of the user
+ * @domain: Domain of the user
* @hentry: Entry in domain user map
* @idr: Smalles possible index number of all users
* @uid: UID of the user
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/12] test: export kdbus_hello_registrar()
On 06/20/2014 06:49 PM, Djalal Harouni wrote: Export this function since we will use it to register policy holders connections. Applied all the test-related patches as well. However, we should probably integrate all these tests in the already existing test framework, so the're all in one place and can all be run with one single binary. But that's a bigger task which can still be done later. Thanks, Daniel Signed-off-by: Djalal Harouni tix...@opendz.org --- test/kdbus-util.c | 2 +- test/kdbus-util.h | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/test/kdbus-util.c b/test/kdbus-util.c index 7a6f272..988aa8c 100644 --- a/test/kdbus-util.c +++ b/test/kdbus-util.c @@ -109,7 +109,7 @@ struct conn *kdbus_hello(const char *path, uint64_t flags) return __kdbus_hello(path, flags, NULL, 0); } -static struct conn * +struct conn * kdbus_hello_registrar(const char *path, const char *name, const struct kdbus_policy_access *access, size_t num_access, uint64_t flags) diff --git a/test/kdbus-util.h b/test/kdbus-util.h index fde3f77..9771622 100644 --- a/test/kdbus-util.h +++ b/test/kdbus-util.h @@ -45,6 +45,9 @@ char *msg_id(uint64_t id, char *buf); int msg_send(const struct conn *conn, const char *name, uint64_t cookie, uint64_t flags, uint64_t timeout, int64_t priority, uint64_t dst_id); struct conn *kdbus_hello(const char *path, uint64_t hello_flags); +struct conn *kdbus_hello_registrar(const char *path, const char *name, +const struct kdbus_policy_access *access, +size_t num_access, uint64_t flags); struct conn *kdbus_hello_activator(const char *path, const char *name, const struct kdbus_policy_access *access, size_t num_access); ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-server: remove unused cleanup function
On Fri, 13.06.14 21:04, Thomas H.P. Andersen (pho...@gmail.com) wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com Removes _cleanup_dhcp_lease_free_. While the automatic cleanup functions are great to have this one is never used and causes a warning in clang. Applied! Thanks! -DEFINE_TRIVIAL_CLEANUP_FUNC(DHCPLease*, dhcp_lease_free); -#define _cleanup_dhcp_lease_free_ _cleanup_(dhcp_lease_freep) - BTW, taking the opportunity for a public service announcement: When I added the _cleanup_() macros I never intended that every single user of it would #define its own _cleanup_foobar_() macro. I just did that for the most common ones, since I didn't want to make visible the fact that internally this requires the indirection via the -p function that DEFINE_TRIVIAL_CLEANUP_FUNC() defines. Not that it really matters, but for cleanup handlers that are never exported in a header file I would probably avoid defining a new macro, and just use DEFINE_TRIVIAL_CLEANUP_FUNC where necesary, and then directly declare my variables with naked _cleanup_() _cleanup_(dhcp_lease_freep) DHCPLease *lease; I mean, if this is not exposed, then there's no need to hide the indirection via the -p function, if you follow what i mean. That all said, this really doesn't matter, so if you feel like defining macros each time go ahead, i won't stop you... ;-) 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 09/12] policy: kdbus_policy_set() use another variable to save entries
On 06/20/2014 06:50 PM, Djalal Harouni wrote:
In kdbus_policy_set() function, we use the 'e' variable to reference
each entry of the 'db-entries_hash', so at the end the variable 'e' will
for sure point to a valid one.
Next in the KDBUS_ITEMS_FOREACH() iterator and if we fail at the first
KDBUS_ITEM_VALID() test, we jmp to exit:
Which contains the following:
if (e)
kdbus_policy_entry_free(e);
This one looks right, but it depends on patch #7.
So the only missing patches from this series are #7 and #9 now.
Daniel
Here 'e' points to a valid entry and it will be freed, so even we
restore all the other entries from that list, there will be always one
missing, the last one pointed by that 'e' variable.
To fix this, just use another 'tmp_entry' variable to reference hash
entries.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/policy.c b/policy.c
index 9cf7f67..601d2a8 100644
--- a/policy.c
+++ b/policy.c
@@ -467,6 +467,7 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
const void *owner)
{
struct kdbus_policy_db_entry *e = NULL;
+ struct kdbus_policy_db_entry *tmp_entry = NULL;
struct kdbus_policy_db_entry_access *a;
const struct kdbus_item *item;
struct hlist_node *tmp;
@@ -483,8 +484,8 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
* At the same time, the lookup mechanism won't find any collisions
* when looking for already exising names.
*/
- hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
- if (e-owner == owner) {
+ hash_for_each_safe(db-entries_hash, i, tmp, tmp_entry, hentry)
+ if (tmp_entry-owner == owner) {
struct kdbus_policy_list_entry *l;
l = kzalloc(sizeof(*l), GFP_KERNEL);
@@ -493,9 +494,9 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
goto exit;
}
- l-e = e;
+ l-e = tmp_entry;
list_add_tail(l-entry, list);
- hash_del(e-hentry);
+ hash_del(tmp_entry-hentry);
}
/* Walk the list of items and look for new policies */
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 12/24] sd-dhcp6-client: Add DHCPv6 Solicit message creation and sending
On Thu, 19.06.14 14:52, Patrik Flykt (patrik.fl...@linux.intel.com) wrote: On Wed, 2014-06-18 at 16:25 +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jun 18, 2014 at 07:05:35AM -0700, Filipe Brandenburger wrote: On Wed, Jun 18, 2014 at 6:58 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: +if (client-fd 0) +safe_close(client-fd); +client-fd = -1; client-fd = safe_close(client-fd); That's what safe_close is for :) And shouldn't the check be for client-fd = 0? Zero is a valid file descriptor. Yeah... but note that safe_close already has the fd = 0 check, so the replacement line replaces the if too. If I omit the client-fd 0 check I get the following in the test case: Assertion 'close_nointr(fd) != -EBADF' failed at src/shared/util.c:205, function safe_close(). Aborting. safe_close() is a call that will ignore all kinds of errors except one: EBADF. THe rationale for that is that the kernel has these weird semantics that close() might fail with errors like EIO or whatever else if something could't be written to disk or so, but the fd will still be closed. Hence, you can invoke safe_close() in all those cases where you just want to get rid of an fd, and don't care about anything else. Now, it will only trip up on one specific problem which always indicates a programming error: when close() returns EBADF, since that is the error that is returned when you invoke close() on an fd that doesn't exist. Putting this all together: safe_close() is basically your one stop solution to getting rid of fds, and even updating your variable you store it in: fd = safe_close(fd); safe_close() always returns -1, always gets rid of the fd, will be a NOP if the fd is 0. Will never fail. However, it if you invoke it the only way that is a real programming error which is with an already-closed fd or a never-opened fd, then it will assert() and die. Hope this makes sense. Or long words short: if the code tripped up like yours above, this is no indication that safe_close() wasn't right. Instead it's an indication that you are passing it a rubbish fd. 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 07/12] policy: use the db-entries_hash to access the policy db entries
On 06/20/2014 07:28 PM, Daniel Mack wrote:
On 06/20/2014 06:50 PM, Djalal Harouni wrote:
Use the db-entries_hash to access the policy db entries instead of the
db-send_access_hash which is just a cache for send entries.
Ah, you're purging the other entries in patch #12. Alright then, now it
makes sense.
Applied both #7 and #9 now.
Thanks,
Daniel
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/policy.c b/policy.c
index bf49f68..79d6fa4 100644
--- a/policy.c
+++ b/policy.c
@@ -373,7 +373,7 @@ static void __kdbus_policy_remove_owner(struct
kdbus_policy_db *db,
struct hlist_node *tmp;
int i;
-hash_for_each_safe(db-send_access_hash, i, tmp, e, hentry)
+hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
Hmm, we need to do both, right? If an owner goes away, we need to kill
both the entries it created *and* the cached entries it is related to.
Now that I look at the code, I see that we miss an owner assignment for
the cache entries. I can fix that up later.
@@ -482,7 +483,7 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
* At the same time, the lookup mechanism won't find any collisions
* when looking for already exising names.
*/
-hash_for_each_safe(db-send_access_hash, i, tmp, e, hentry)
+hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
if (e-owner == owner) {
struct kdbus_policy_list_entry *l;
This change looks right though.
Daniel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files
On Tue, 14.05.13 19:09, Oleksii Shevchuk (alx...@gmail.com) wrote: Heya! Sorry for resurrecting this thread from last year. I never found the time to merge this, but I finally had a closer look and then sat down and tried to isolate out of it what I liked and what I didn't. I commited different patches for this though. Sorry for the long delay! So here's what is implemented in git now: a) There's a configuration file /etc/systemd/coredump.conf with some of the options you proposed. b) We will now store coredumps outside of the journal by default, but you can also place them in the journal only, or at both places. c) I hooked this thing up with elfutils' libdw, which gives us pretty, native backtraces in the journal now, without involving gdb or anything like that. Only a minimal (optional) dependency on libdw to get them. And the best thing is that elfutils is actually maintained and can read debuginfo files, unlike some other options for stuff like this (like libunwind). d) I hooked this up with ACLs so that a user can read but not change his own coredumps stored in /var. What I didn't take: 1) the API to specify external programs for compressing or processing the coredumps. I am really not too fond of doing things with invokign external programs. THat's always chickening out in my eyes, avoiding to solve the problems properly. By using elfutils' libdw we get the backtrace feature nicely integrated now without invoking external programs, I guess the need for PreprocessJournal= is hence redundant with that. There's no support for compression though, but I'd be fine with taking a simple patch for that that directly speaks to the xz APIs. After all we link against the xz already. Of course this would need support in both the coredump hook to transparently compress the coredumps and in coredumpctl on the client side so that coredumpctl gdb just works without manual decompression. 2) I change the paths to store this in. I drop the coredumps in /var/lib/systemd/coredump/ now. While the journal logs appear to be something worth sharing across the network as logs; I am not convinced that the coredumps would fit that category. Anyway, I hope this makes sense. With these changes coredumpctl actually is now really useful and just works. I have thus dropped the systemd- prefix. We should probably start advertising it more. 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] man: systemd.net devwork
On Fri, 20.06.14 19:26, poma (pomidorabelis...@gmail.com) wrote: Perhaps Ding Dong! :) Please be patient. We try to look into all patches one by one. I have a huge backlog, and I know that Tom (whose area of expertise this mostly is) is busy. We won't forget the patch, it just takes time to process all the patches. 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 07/12] policy: use the db-entries_hash to access the policy db entries
On Fri, Jun 20, 2014 at 08:01:04PM +0200, Daniel Mack wrote:
On 06/20/2014 07:28 PM, Daniel Mack wrote:
On 06/20/2014 06:50 PM, Djalal Harouni wrote:
Use the db-entries_hash to access the policy db entries instead of the
db-send_access_hash which is just a cache for send entries.
Ah, you're purging the other entries in patch #12. Alright then, now it
makes sense.
Indeed, I've tested it and the cache is cleared.
Applied both #7 and #9 now.
Thank you Daniel, There is a still another series related to the cache I
just need to test it.
When we update the TALK POLICY of a connection that is already
referenced as a *destination* in the cache we must purge all its entries
from the cache, since permission have been changed! we need to redo the
permission checks.
This should be done in kdbus_policy_set() when we update the TALK policy
but since kdbus_policy_set() can be called by an endpoint as an owner,
not only a connection, I did split the code in a new function...
Anyway I'll test it send it tomorrow.
Thanks,
Daniel
Signed-off-by: Djalal Harouni tix...@opendz.org
---
policy.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/policy.c b/policy.c
index bf49f68..79d6fa4 100644
--- a/policy.c
+++ b/policy.c
@@ -373,7 +373,7 @@ static void __kdbus_policy_remove_owner(struct
kdbus_policy_db *db,
struct hlist_node *tmp;
int i;
- hash_for_each_safe(db-send_access_hash, i, tmp, e, hentry)
+ hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
Hmm, we need to do both, right? If an owner goes away, we need to kill
both the entries it created *and* the cached entries it is related to.
Now that I look at the code, I see that we miss an owner assignment for
the cache entries. I can fix that up later.
@@ -482,7 +483,7 @@ int kdbus_policy_set(struct kdbus_policy_db *db,
* At the same time, the lookup mechanism won't find any collisions
* when looking for already exising names.
*/
- hash_for_each_safe(db-send_access_hash, i, tmp, e, hentry)
+ hash_for_each_safe(db-entries_hash, i, tmp, e, hentry)
if (e-owner == owner) {
struct kdbus_policy_list_entry *l;
This change looks right though.
Daniel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Djalal Harouni
http://opendz.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: systemd.net devwork
On Tue, 17.06.14 11:27, poma (pomidorabelis...@gmail.com) wrote: Hmm, can make this a proper git patch, i.e. with a useful commit msg we can just commit? That would make it a lot easier. TOm probably should review this, it's his area of expertise. Tom? (Oh, and while we don't strictly require it, we do prefer commiting stuff with real names. Unless you want to stay anonymous, it would be great if you could post patches at least with a realname. Thanks) Thanks! 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] Linking user-session services to a systemd-logind session
On Thu, 19.06.14 16:21, Elias Probst (m...@eliasprobst.eu) wrote: Hi list, I'm working on getting (at least the basics for now) ready to run a KF5 based Plasma Workspace session completely based on systemd user-session services to get rid of the legacy cruft shell-based startkde script and get to use all the nice things systemd offers. Note that the session stuff isn't complete yet. We kinda wait for kdbus there, to make it complete, and kdbus is currently stalling on memfd. And memfd is currently on its way in... I'm currently stuck trying to make 'ksmserver' (Plasma's session management server) the owner of the current session using Session.TakeControl(), as user-session services aren't part of a session. TakeControl is really something for display servers like X11, not for app or desktop code. X11 has aleady been updated to use it, you should not have to call it unless you implement your own display server. 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] mdns support to networkd
On Sat, 14.06.14 01:13, Vasiliy Tolstov (v.tols...@selfip.ru) wrote: As i see avahi development stopped. Well, yeah, I am doign a shitty job at maintaining it. Does mdns support goes to networkd or no? Well, no. But into systemd-resolved. Our plan is to turn systemd-resolved into an nscd compatible daemon that speaks dns/dnssec, mdns, llmnr, in the long run replacing avahi. 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] man: systemd.net devwork
On Fri, Jun 20, 2014 at 8:12 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 17.06.14 11:27, poma (pomidorabelis...@gmail.com) wrote: Hmm, can make this a proper git patch, i.e. with a useful commit msg we can just commit? That would make it a lot easier. TOm probably should review this, it's his area of expertise. Tom? (Oh, and while we don't strictly require it, we do prefer commiting stuff with real names. Unless you want to stay anonymous, it would be great if you could post patches at least with a realname. Thanks) Hi Poma, Thanks for the patch, and sorry for the delay. I'll try to get it reviewed and merged on Monday. At a quick glance, I'd drop the this has only been tested with ... line (not to say that more testing wouldn't be good, but I don't think the manpage is the place to ask for that). Also, if you could resubmit as suggested by Lennart hat would make my job a lot easier :) Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Remove libattr mentions from README
On Thu, 12.06.14 15:40, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: It is no longer required. Indeed! Thanks! Applied! --- README | 1 - 1 file changed, 1 deletion(-) diff --git a/README b/README index de159fe..2fd95e9 100644 --- a/README +++ b/README @@ -115,7 +115,6 @@ REQUIREMENTS: libcryptsetup (optional) libaudit (optional) libacl (optional) -libattr (optional) libselinux (optional) liblzma (optional) libgcrypt (optional) 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 2/2] dhcp-network: don't bother with IP fragments
Looks good to me. Please push. -t On Thu, Jun 19, 2014 at 6:59 PM, Michal Sekletar msekl...@redhat.com wrote: --- src/libsystemd-network/dhcp-network.c | 4 1 file changed, 4 insertions(+) diff --git a/src/libsystemd-network/dhcp-network.c b/src/libsystemd-network/dhcp-network.c index e5fd6a8..f500bff 100644 --- a/src/libsystemd-network/dhcp-network.c +++ b/src/libsystemd-network/dhcp-network.c @@ -41,6 +41,10 @@ int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link, BPF_STMT(BPF_LD + BPF_B + BPF_ABS, offsetof(DHCPPacket, ip.protocol)), /* A - IP protocol */ BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 1, 0), /* IP protocol == UDP ? */ BPF_STMT(BPF_RET + BPF_K, 0), /* ignore */ +BPF_STMT(BPF_LD + BPF_H + BPF_ABS, offsetof(DHCPPacket, ip.frag_off)), /* A - Flags + Fragment offset */ +BPF_STMT(BPF_ALU + BPF_AND + BPF_K, 0x1fff), /* A - A 0x1fff */ +BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0, 1, 0), /* A == 0 ? */ +BPF_STMT(BPF_RET + BPF_K, 0), /* ignore */ BPF_STMT(BPF_LD + BPF_H + BPF_ABS, offsetof(DHCPPacket, udp.dest)),/* A - UDP destination port */ BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, DHCP_PORT_CLIENT, 1, 0), /* UDP destination port == DHCP client port ? */ BPF_STMT(BPF_RET + BPF_K, 0), /* ignore */ -- 2.0.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mdns support to networkd
On Fri, Jun 20, 2014 at 08:19:17PM +0200, Lennart Poettering wrote: On Sat, 14.06.14 01:13, Vasiliy Tolstov (v.tols...@selfip.ru) wrote: As i see avahi development stopped. Well, yeah, I am doign a shitty job at maintaining it. Does mdns support goes to networkd or no? Well, no. But into systemd-resolved. Our plan is to turn systemd-resolved into an nscd compatible daemon that speaks dns/dnssec, mdns, llmnr, in the long run replacing avahi. Is there a intersection with SSSD? It is quite heavily promoted by one company with color headgear in name, and slighlty conflicts with nscd (and compatibile) solutions: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/usingnscd-sssd.html -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 214
On Thu, 12.06.14 03:36, Cameron Norman (camerontnor...@gmail.com) wrote: El Wed, 11 de Jun 2014 a las 10:00 AM, Lennart Poettering lenn...@poettering.net escribió: Hi! http://www.freedesktop.org/software/systemd/systemd-214.tar.xz Here it is, version 214. Stuffed with great new features, improvements in all areas, 1 I would think that removing m from the documentation entirely would make it hard for people looking at old tmpfile configurations to understand what m does. Why not keep it in the docs, but clearly mark it as deprecated? Well, it's how we have done things so far. It's a balance between keeping things minimal+simple and trying to cover all the history of our codebase in the docs. I tend to prefer the former (however, making this changes clear in NEWS files), but I can see how others might prefer the latter. 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] machined: updating the PID of a created machine
On Thu, 12.06.14 17:20, Cedric Bosdonnat (cbosdon...@suse.com) wrote: Hi all, (replying to your original mail, I did see your later patch, but I thought to focus on the background of the patch) In libvirt lxc driver's use of machined, the CreateMachine call is sent out before the init process is actually started. This gives libvirt lxc driver some time to setup the container before starting it. Not following here... What time is meant there? The idea is that CreateMachine is either invoked from the child when the system is fully set up, right before droppping privs. Or that it is invoked from the parent at that point. You need some kind of synchronization when invoking CreateMachine, you shouldn't allow this to race freely against each other. Among other reasons this becomes really problematic as soon as you use the devices cgroup controller, as then CreateMachine() might take away device access (including the ability to mknod() specific device nodes). This means you need to populate /dev for the container before invoking CreateMachine, but then you also need to make sure CreateMachine is complete before you invoke your container userspace... However, the leader PID sent isn't the proper one and functions like machinectl login are failing. Would it be possible to add an API to update the Leader PID of a machine after its creation? Hmm, why isn't the right leader PID set? Not following? Our other solution would be to start the init process and send it to sleep to be able to continue setting up the container... but that means costly (and maybe fragile) refactoring. Well, you have to fork, set up things, then tell the parent you are ready to get cgroupified, then wait for that to be complete, then exec() your real userspace. I don't think thre's a real way around that in the long run... 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] mdns support to networkd
On Fri, 20.06.14 20:35, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Fri, Jun 20, 2014 at 08:19:17PM +0200, Lennart Poettering wrote: On Sat, 14.06.14 01:13, Vasiliy Tolstov (v.tols...@selfip.ru) wrote: As i see avahi development stopped. Well, yeah, I am doign a shitty job at maintaining it. Does mdns support goes to networkd or no? Well, no. But into systemd-resolved. Our plan is to turn systemd-resolved into an nscd compatible daemon that speaks dns/dnssec, mdns, llmnr, in the long run replacing avahi. Is there a intersection with SSSD? It is quite heavily promoted by one company with color headgear in name, and slighlty conflicts with nscd (and compatibile) solutions: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/usingnscd-sssd.html Well, we have no intention to do anything fancy with users/groups at this time. We do this only for hostnames and stuff, which should be fine and compatible with sssd. 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] mdns support to networkd
Lennart Poettering lenn...@poettering.net on Fri, 2014/06/20 20:19:
On Sat, 14.06.14 01:13, Vasiliy Tolstov (v.tols...@selfip.ru) wrote:
As i see avahi development stopped.
Well, yeah, I am doign a shitty job at maintaining it.
Does mdns support goes to networkd or no?
Well, no. But into systemd-resolved. Our plan is to turn
systemd-resolved into an nscd compatible daemon that speaks dns/dnssec,
mdns, llmnr, in the long run replacing avahi.
Does this cover server functionality only or will there be client bits as
well?
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
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 12/24] sd-dhcp6-client: Add DHCPv6 Solicit message creation and sending
On Fri, Jun 20, 2014 at 07:45:39PM +0200, Lennart Poettering wrote: On Thu, 19.06.14 14:52, Patrik Flykt (patrik.fl...@linux.intel.com) wrote: On Wed, 2014-06-18 at 16:25 +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jun 18, 2014 at 07:05:35AM -0700, Filipe Brandenburger wrote: On Wed, Jun 18, 2014 at 6:58 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: +if (client-fd 0) +safe_close(client-fd); +client-fd = -1; client-fd = safe_close(client-fd); That's what safe_close is for :) And shouldn't the check be for client-fd = 0? Zero is a valid file descriptor. Yeah... but note that safe_close already has the fd = 0 check, so the replacement line replaces the if too. If I omit the client-fd 0 check I get the following in the test case: Assertion 'close_nointr(fd) != -EBADF' failed at src/shared/util.c:205, function safe_close(). Aborting. safe_close() is a call that will ignore all kinds of errors except one: EBADF. THe rationale for that is that the kernel has these weird semantics that close() might fail with errors like EIO or whatever else if something could't be written to disk or so, but the fd will still be closed. Hence, you can invoke safe_close() in all those cases where you just want to get rid of an fd, and don't care about anything else. Now, it will only trip up on one specific problem which always indicates a programming error: when close() returns EBADF, since that is the error that is returned when you invoke close() on an fd that doesn't exist. Putting this all together: safe_close() is basically your one stop solution to getting rid of fds, and even updating your variable you store it in: fd = safe_close(fd); safe_close() always returns -1, always gets rid of the fd, will be a NOP if the fd is 0. Will never fail. However, it if you invoke it the only way that is a real programming error which is with an already-closed fd or a never-opened fd, then it will assert() and die. Hope this makes sense. Or long words short: if the code tripped up like yours above, this is no indication that safe_close() wasn't right. Instead it's an indication that you are passing it a rubbish fd. Yeah, fixed in c806ffb. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Warning/error systemd-networkd
Hey, folks. When i try to start systemd-networkd systemctl start systemd-networkd with conf file (pasted), service/daemon works, but returns this warning/error in status: Jun 20 16:36:44 delphi systemd-networkd[4271]: eth0: gained carrier Jun 20 16:36:44 delphi systemd[1]: Started Network Service. Jun 20 16:36:44 delphi systemd-networkd[4271]: *rtnl: received address for a nonexistent link, ignoring* Jun 20 16:36:44 delphi systemd-networkd[4271]: eth0: link configured My static.network file is: [Match] Name=eth0 [Network] Address=2604:180::4bf4:91cb/64 Gateway=2604:180::1 [Network] Address=107.191.125.32/24 Gateway=107.191.125.1 In another way of sections, confs run/works, but same error/warning shows. I'm on Archlinux and my systemd version is last stable one. Bug-fix needed? Att, Luis Mauricio Costa. Cientista da Computação. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files
2014-06-20 20:02 GMT+02:00 Lennart Poettering lenn...@poettering.net: So here's what is implemented in git now: a) There's a configuration file /etc/systemd/coredump.conf with some of the options you proposed. b) We will now store coredumps outside of the journal by default, but you can also place them in the journal only, or at both places. c) I hooked this thing up with elfutils' libdw, which gives us pretty, native backtraces in the journal now, without involving gdb or anything like that. Only a minimal (optional) dependency on libdw to get them. And the best thing is that elfutils is actually maintained and can read debuginfo files, unlike some other options for stuff like this (like libunwind). d) I hooked this up with ACLs so that a user can read but not change his own coredumps stored in /var. [..] With these changes coredumpctl actually is now really useful and just works. I have thus dropped the systemd- prefix. We should probably start advertising it more. Nice stuff, thanks. We currently disable coredump support in Debian but with those changes it's time to revisit that. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: require elfutils = 158
The recently added stacktrace support in 8d4e028f uses functions added
in elfutils 158. Check for one of the new functions to avoid attempting
to build against older versions.
---
configure.ac | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1391d03..c1f83ee 100644
--- a/configure.ac
+++ b/configure.ac
@@ -639,7 +639,7 @@ AC_ARG_ENABLE([elfutils],
if test x${have_elfutils} != xno ; then
AC_CHECK_HEADERS(
[elfutils/libdwfl.h],
-[have_elfutils=yes],
+[],
[if test x$have_elfutils = xyes ; then
AC_MSG_ERROR([*** ELFUTILS headers not found.])
fi])
@@ -647,11 +647,19 @@ if test x${have_elfutils} != xno ; then
AC_CHECK_LIB(
[dw],
[dwfl_begin],
-[have_elfutils=yes],
+[],
[if test x$have_elfutils = xyes ; then
AC_MSG_ERROR([*** ELFUTILS libs not found.])
fi])
+AC_CHECK_LIB(
+[dw],
+[dwfl_core_file_attach],
+[have_elfutils=yes],
+[if test x$have_elfutils = xyes ; then
+AC_MSG_ERROR([*** ELFUTILS = 158 is required.])
+fi])
+
if test x$have_elfutils = xyes ; then
ELFUTILS_LIBS=-lelf -ldw
AC_DEFINE(HAVE_ELFUTILS, 1, [ELFUTILS available])
--
1.8.5.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fix systemd-resolved reference in man page
Guess this was missed in the copy-paste :-) --- man/systemd-resolved.service.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd-resolved.service.xml b/man/systemd-resolved.service.xml index ed1f5a23658f..517e08ef2bd5 100644 --- a/man/systemd-resolved.service.xml +++ b/man/systemd-resolved.service.xml @@ -56,7 +56,7 @@ refsect1 titleDescription/title -paracommandsystemd-networkd/command is a system +paracommandsystemd-resolved/command is a system service that manages network name resolution. It does so by generating filename/run/systemd/resolve/resolv.conf/filename, which may be symlinked from filename/etc/resolv.conf/filename. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] consistently order cleanup attribute before type
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
---
src/cgls/cgls.c| 2 +-
src/journal/journal-remote-parse.c | 4 ++--
src/journal/journal-remote.c | 8
src/journal/microhttpd-util.c | 2 +-
src/nspawn/nspawn.c| 2 +-
src/readahead/readahead-common.c | 2 +-
src/shared/fileio.c| 2 +-
src/shared/sleep-config.c | 2 +-
src/shared/socket-label.c | 2 +-
src/test/test-path-util.c | 2 +-
10 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/cgls/cgls.c b/src/cgls/cgls.c
index bec9b59..052ac8f 100644
--- a/src/cgls/cgls.c
+++ b/src/cgls/cgls.c
@@ -130,7 +130,7 @@ static int parse_argv(int argc, char *argv[]) {
int main(int argc, char *argv[]) {
int r = 0, retval = EXIT_FAILURE;
int output_flags;
-char _cleanup_free_ *root = NULL;
+_cleanup_free_ char *root = NULL;
_cleanup_bus_unref_ sd_bus *bus = NULL;
log_parse_environment();
diff --git a/src/journal/journal-remote-parse.c
b/src/journal/journal-remote-parse.c
index 239ff38..dbdf02a 100644
--- a/src/journal/journal-remote-parse.c
+++ b/src/journal/journal-remote-parse.c
@@ -177,7 +177,7 @@ static int fill_fixed_size(RemoteSource *source, void
**data, size_t size) {
static int get_data_size(RemoteSource *source) {
int r;
-void _cleanup_free_ *data = NULL;
+_cleanup_free_ void *data = NULL;
assert(source);
assert(source-state == STATE_DATA_START);
@@ -215,7 +215,7 @@ static int get_data_data(RemoteSource *source, void **data)
{
static int get_data_newline(RemoteSource *source) {
int r;
-char _cleanup_free_ *data = NULL;
+_cleanup_free_ char *data = NULL;
assert(source);
assert(source-state == STATE_DATA_FINISH);
diff --git a/src/journal/journal-remote.c b/src/journal/journal-remote.c
index 31401fb..a31dc2c 100644
--- a/src/journal/journal-remote.c
+++ b/src/journal/journal-remote.c
@@ -139,7 +139,7 @@ static int spawn_curl(char* url) {
static int spawn_getter(char *getter, char *url) {
int r;
-char _cleanup_strv_free_ **words = NULL;
+_cleanup_strv_free_ char **words = NULL;
assert(getter);
words = strv_split_quoted(getter);
@@ -154,7 +154,7 @@ static int spawn_getter(char *getter, char *url) {
}
static int open_output(Writer *s, const char* url) {
-char _cleanup_free_ *name, *output = NULL;
+_cleanup_free_ char *name, *output = NULL;
char *c;
int r;
@@ -745,8 +745,8 @@ static int remoteserver_init(RemoteServer *s) {
}
if (arg_url) {
-char _cleanup_free_ *url = NULL;
-char _cleanup_strv_free_ **urlv = strv_new(arg_url,
/entries, NULL);
+_cleanup_free_ char *url = NULL;
+_cleanup_strv_free_ char **urlv = strv_new(arg_url,
/entries, NULL);
if (!urlv)
return log_oom();
url = strv_join(urlv, );
diff --git a/src/journal/microhttpd-util.c b/src/journal/microhttpd-util.c
index 9a8d5c6..007cb5d 100644
--- a/src/journal/microhttpd-util.c
+++ b/src/journal/microhttpd-util.c
@@ -217,7 +217,7 @@ int check_permissions(struct MHD_Connection *connection,
int *code) {
const union MHD_ConnectionInfo *ci;
gnutls_session_t session;
gnutls_x509_crt_t client_cert;
-char _cleanup_free_ *buf = NULL;
+_cleanup_free_ char *buf = NULL;
int r;
assert(connection);
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 8270348..212f722 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -824,7 +824,7 @@ static int setup_timezone(const char *dest) {
}
static int setup_resolv_conf(const char *dest) {
-char _cleanup_free_ *where = NULL;
+_cleanup_free_ char *where = NULL;
assert(dest);
diff --git a/src/readahead/readahead-common.c b/src/readahead/readahead-common.c
index 890886e..eda99e8 100644
--- a/src/readahead/readahead-common.c
+++ b/src/readahead/readahead-common.c
@@ -226,7 +226,7 @@ int open_inotify(void) {
}
ReadaheadShared *shared_get(void) {
-int _cleanup_close_ fd = -1;
+_cleanup_close_ int fd = -1;
ReadaheadShared *m = NULL;
mkdirs();
diff --git a/src/shared/fileio.c b/src/shared/fileio.c
index c7b2cd8..c580624 100644
--- a/src/shared/fileio.c
+++ b/src/shared/fileio.c
@@ -708,7 +708,7 @@ int write_env_file(const char *fname, char **l) {
int executable_is_script(const char *path, char **interpreter) {
int r;
-char _cleanup_free_ *line = NULL;
+_cleanup_free_ char *line = NULL;
int len;
char *ans;
diff --git a/src/shared/sleep-config.c b/src/shared/sleep-config.c
index 1972cdb..867e4ed 100644
--- a/src/shared/sleep-config.c
+++ b/src/shared/sleep-config.c
@@ -49,7 +49,7 @@ int
[systemd-devel] udev-212 and up on Sparc v8
udev up to version 208 builds correctly on Sparc v8. However 212 and greater does not. Complete build logs of 208 and 214 can be found here: https://bugs.gentoo.org/show_bug.cgi?id=514016 Any suggestions or alternatives to how we can fix this would be appreciated. This affects old Sun hardware, Leon Sparc, and the sparc implementation being developed at temlib.org it may also affect other architectures that I am not aware of. Thanks,Chase Rayfield ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
On 21/06/14 08:38, Chase Rayfield wrote: udev up to version 208 builds correctly on Sparc v8. However 212 and greater does not. Complete build logs of 208 and 214 can be found here: https://bugs.gentoo.org/show_bug.cgi?id=514016 Any suggestions or alternatives to how we can fix this would be appreciated. This affects old Sun hardware, Leon Sparc, and the sparc implementation being developed at temlib.org it may also affect other architectures that I am not aware of. Thanks, Chase Rayfield When I suggested you report this to the mailing list, I expected you to extract systemd tarball, run export CFLAGS=-mcpu=v8, ./configure and make And post the output from that here I also didn't expect the bug to be referenced, but instead the relavent information posted here, so non-Gentoo people don't have to parse the Gentoo-specific bug Sorry, I should have been more clear about it Thanks, Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
