[systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Eric Biggers
Hello, The latest systemd README and NEWS claim that the userspace interface to the in-kernel hash algorithms (CONFIG_CRYPTO_USER_API_HASH) is now required. I don't know how much thought was put into this decision, but I think it's a mistake security-wise. AF_ALG sockets increase the kernel's

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

2017-03-20 Thread Mantas Mikulėnas
First thought: Even without the exit code or anything, it's going to be -EBUSY like 99.999% of the time. Not much else can fail during umount. And ”Filesystem is busy" would perfectly fit the earlier error message which you overlooked: "Process 304 (plymouthd) has been marked to be excluded from

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

2017-03-20 Thread Chris Murphy
Any thoughts on this? I've followed these instructions: https://freedesktop.org/wiki/Software/systemd/Debugging/ Shutdown Completes Eventually However, no additional information is being logged that gives any answer to why there are three remount ro attempts, and why they aren't succeeding.

Re: [systemd-devel] nsapwned container terminal background color

2017-03-20 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Mar 20, 2017 at 08:34:02AM +, arnaud gaboury wrote: > > > Are you starting the container manually using systemd-nspawn in a > > terminal > > > emulator window? > > Not really. The container is started at machine boot with > systemd-nspawn@container.service. Then, in one urxvt

Re: [systemd-devel] nsapwned container terminal background color

2017-03-20 Thread arnaud gaboury
On Mon, Mar 20, 2017 at 5:12 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Sun, Mar 19, 2017 at 09:30:05PM +, Zbigniew Jędrzejewski-Szmek > wrote: > > On Sun, Mar 19, 2017 at 04:37:53PM +, arnaud gaboury wrote: > > > I am trying with no success to have one background

Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread D.S. Ljungmark
I find your argument to be strange. "The kernel has this functionality, please do not use it and rather reimplement it in every piece of userspace that ever needs it, because that's supposed to be more secure." I simply don't buy your argument here. //D.S. On Mon, Mar 20, 2017 at 8:22 AM, Eric

Re: [systemd-devel] sd-bus connections & authentication timeout

2017-03-20 Thread Jan Alexander Steffens
On Mon, Mar 20, 2017, 16:37 Stanislav Angelovič wrote: > Hi, > > We use sd-bus for DBus IPC in our own applications. Some applications of > ours cause the dbus daemon to issue "Connection has not authenticated soon > enough, closing it" message, leading to the >

Re: [systemd-devel] sd-bus connections & authentication timeout

2017-03-20 Thread Jan Alexander Steffens
On Mon, Mar 20, 2017, 17:14 Jan Alexander Steffens wrote: > > You could try calling sd_bus_process(bus, NULL) in a loop while it returns > >0 so that the initial hello is handled. > Actually, never mind, this is not reliable. IIRC the initial handshake has multiple steps

Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Cristian Rodríguez
El 20-03-2017 a las 10:26, D.S. Ljungmark escribió: > I find your argument to be strange. > > "The kernel has this functionality, please do not use it and rather > reimplement it in every piece of userspace that ever needs it, because > that's supposed to be more secure." > > I simply don't

Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Mantas Mikulėnas
On Mon, Mar 20, 2017 at 3:50 PM, Cristian Rodríguez < crrodrig...@opensuse.org> wrote: > > > El 20-03-2017 a las 10:26, D.S. Ljungmark escribió: > > I find your argument to be strange. > > > > "The kernel has this functionality, please do not use it and rather > > reimplement it in every piece of

[systemd-devel] sd-bus connections & authentication timeout

2017-03-20 Thread Stanislav Angelovič
Hi, We use sd-bus for DBus IPC in our own applications. Some applications of ours cause the dbus daemon to issue "Connection has not authenticated soon enough, closing it" message, leading to the org.freedesktop.DBus.Error.Timeout error at the peer side when the connection is used for an IPC

[systemd-devel] socket / service dependency

2017-03-20 Thread Ken Bass
I thought I followed the instructions (using Centos 7 - I believe systemd219) ... I am running a local news server (innd.service). I needed to add an additional inetd style daemon for nnrpd to support SSL. See files below. Using the BindTo and After seems proper since I never want nnrpd

Re: [systemd-devel] sd-bus connections & authentication timeout

2017-03-20 Thread Stanislav Angelovič
Hi Jan, thanks for quick response. Instead of sd_bus_process(), we could perhaps use sd_bus_flush() after creating the connection, as that one actually processes the requests until the connection changes state to 'running'. I tried this and it helped. Regarding polling, I understand, but I fear