[systemd-devel] Socket activation of container with private network

[sbaugh]

--text follows this line--

Hi,

I am having trouble with socket-activated containers, where the socket
is first opened outside the container, on an interface/IP address that
is then passed in to the container.

In short, when I try to ssh to the IP address of the container, the
container is indeed activated as it should be, but ssh fails with:

  Read from socket failed: Connection reset by peer

I believe this is due to the ssh connection successfully starting then
being interrupted by something unknown before it can prompt for a
password, but not sure what this unknown thing is - systemd, networking
setup, something else?

In more detail, I have a script, interface-setup.sh, to create a
veth. (Contents of the script are at the end of this email.) One end of
the veth is added to a bridge, and the other end gets an IPv6
address. That end will be sent into the container. Outside of the
container, I bind to that address with the following .socket unit.

# /etc/systemd/system/container-nspawn.socket
  [Unit]
  Description=The SSH socket of my little container

  [Socket]
  ExecStartPre=/srv/interface-setup.sh
  ListenStream=[2001:470:8:9d:201:2ff:feaa:bbcd]:23
  ExecStopPost=/srv/interface-teardown.sh
  FreeBind=yes

And I have the following corresponding .service unit.

# /etc/systemd/system/container-nspawn.service
  [Unit]
  Description=Contributed Container for sbaugh/debian-safe

  [Service]
  ExecStart=/usr/bin/systemd-nspawn --keep-unit -b 
--network-interface=sbaugh-veth1 --directory=/srv/debian-safe 3
  KillMode=process

Inside the container, I have the following two unit files:

# /srv/debian-safe/etc/systemd/system/sshd@.service
  [Unit]
  Description=SSH Per-Connection Server for %I

  [Service]
  ExecStart=-/usr/sbin/sshd -i
  StandardInput=socket

# /srv/debian-safe/etc/systemd/system/sshd.socket
  [Unit]
  Description=SSH Socket for Per-Connection Servers

  [Socket]
  ListenStream=[2001:470:8:9d:201:2ff:feaa:bbcd]:23
  # repeat ListenStream twice as per
  # 
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028232.html
  ListenStream=[2001:470:8:9d:201:2ff:feaa:bbcd]:23
  FreeBind=yes
  Accept=yes

I can start the socket on the host just fine:

  ● container-nspawn.socket - The SSH socket of my little container
 Loaded: loaded (/etc/systemd/system/container-nspawn.socket; static; 
vendor preset: enabled)
Drop-In: /etc/systemd/system/container-nspawn.socket.d
 └─override.conf
 Active: active (listening) since Fri 2015-04-17 17:21:08 EDT; 17s ago
 Listen: [2001:470:8:9d:201:2ff:feaa:bbcd]:23 (Stream)
Process: 1239 ExecStartPre=/srv/interface-setup.sh (code=exited, 
status=0/SUCCESS)
  
  Apr 17 17:21:08 ipv6-test systemd[1]: Starting The SSH socket of my little 
container.
  Apr 17 17:21:08 ipv6-test systemd[1]: Listening on The SSH socket of my 
little container.
  
When I ssh from another machine to this container's IPv6 address, it
gets activated as it should:
  
  ● container-nspawn.service - Contributed Container for sbaugh/debian-safe
 Loaded: loaded (/etc/systemd/system/container-nspawn.service; static; 
vendor preset: enabled)
 Active: active (running) since Fri 2015-04-17 17:21:31 EDT; 10s ago
   Main PID: 1262 (systemd-nspawn)
 CGroup: /system.slice/container-nspawn.service
 ├─1262 /usr/bin/systemd-nspawn --keep-unit -b 
--network-interface=sbaugh-veth1 --directory=/srv/debian-safe 3
 ├─1263 /lib/systemd/systemd 3
 └─system.slice
   ├─cron.service
   │ └─1332 /usr/sbin/cron -f
   ├─system-sshd.slice
   │ 
└─sshd@0-2001:470:8:9d:201:2ff:feaa:bbcd:23-2001:470:7:12f::2:42162.service
   │   ├─1331 sshd: [accepted]
   │   └─1343 sshd: [net]
   ├─systemd-journald.service
   │ └─1283 /lib/systemd/systemd-journald
   ├─systemd-networkd.service
   │ └─1278 /lib/systemd/systemd-networkd
   ├─console-getty.service
   │ └─1339 /sbin/agetty --noclear --keep-baud console 115200 
38400 9600 vt102
   └─rsyslog.service
 └─1334 /usr/sbin/rsyslogd -n
  
  Apr 17 17:21:32 ipv6-test systemd-nspawn[1262]: [  OK  ] Started Permit User 
Sessions.
  Apr 17 17:21:32 ipv6-test systemd-nspawn[1262]: Starting Console Getty...
  Apr 17 17:21:32 ipv6-test systemd-nspawn[1262]: [  OK  ] Started Console 
Getty.
  Apr 17 17:21:32 ipv6-test systemd-nspawn[1262]: [  OK  ] Reached target Login 
Prompts.
  Apr 17 17:21:32 ipv6-test systemd-nspawn[1262]: [  OK  ] Started System 
Logging Service.
  Apr 17 17:21:32 ipv6-test systemd-nspawn[1262]: [  OK  ] Reached target 
Multi-User System.
  Apr 17 17:21:32 ipv6-test systemd-nspawn[1262]: Starting Update UTMP about 
System Runlevel Changes...
  Apr 17 17:21:32 ipv6-test systemd-nspawn[1262]: [  OK  ] Started Cleanup of 
Tem

Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Matt Hoosier]

On Fri, Apr 17, 2015 at 3:52 PM, Cristian Rodríguez <
crrodrig...@opensuse.org> wrote:

> On Fri, Apr 17, 2015 at 4:06 PM, Matt Hoosier 
> wrote:
> > On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering
> >  wrote:
> >>
> >> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@gmail.com) wrote:
> >>
> >> > Hi,
> >> >
> >> > I'm writing to see whether there's a "best" way to allow systemd to
> >> > inherit
> >> > ownership of a process forked from a hand-crafted /sbin/init process
> >> > before
> >> > that hand-crafted process turns over the keys to systemd by doing
> >> > exec("/lib/systemd/systemd") over the top of itself and allowing it to
> >> > take
> >> > over as PID 1.
> >>
> >> We support this only really for "kernel-like" processes that are
> >> started from the initrd, and basically run as long as the system is up
> >> without every being restarted in between, thus effectively appearing
> >> much like a kernel process and nothing systemd should
> >> manage. Processes like this should be marked with argv[0][0] = '@',
> >> see for details:
> >>
> >> https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/
> >>
> >> > I know that sounds like an odd thing to ask about. The use-case has to
> >> > do
> >> > with being able to start some work extremely early during boot of
> >> > embedded
> >> > systems to achieve performance goals. I don't wish to subvert systemd,
> >> > and
> >> > in fact would love for systemd to be able to monitor the process, stop
> >> > it,
> >> > restart according to the normal [Service] configuration in a unit file
> >> > describing the process.
> >>
> >> Hmm, are you sure that invoking the binary from systemd as first
> >> service is really that much slower than starting systemd only
> afterwards?
> >
> >
> > The bootcharting that I do seems to show that about 1.2 - 1.5 sec are
> spent
> > internal to systemd before any external processes get run for the
> particular
> > embedded CPU I'm using. That gap is a killer at the moment.
>
> Did you watch this presentation ?
>
> https://www.youtube.com/watch?v=RFVlbaDqll8
>
> what part of systemd is taking 1.5 seconds to start, on what CPU and
> how much of RAM does the board has ?
>

Thanks, I hadn't found that presentation before. My board is essentially a
Panda ES, with gigabytes of RAM.

A small point of clarification: when I say that systemd takes 1.5 seconds,
I'm referring to the time that elapses between the moment that
/lib/systemd/systemd is exec'ed and the time that the first unit is shown
in the 'systemd-analyze plot'. I haven't done an internal profile on the
systemd binary to see what might be happening during that window yet.

Could you say a word more about the sys_accept4() and /sys/fs/cgroup issue?
Was its only symptom that it caused systemd to run slower?

-Matt
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] machinectl login fails systemd 219

[Keller, Jacob E]

On Fri, 2015-04-17 at 18:40 +, Keller, Jacob E wrote:
> On Wed, 2015-04-15 at 00:07 +0200, Stefan Tatschner wrote:
> > On Di, 2015-04-14 at 21:56 +, Keller, Jacob E wrote:
> > > Failed to get machine PTY: Message did not receive a reply (timeout 
> > > by message bus)
> > > 
> > > I get a notification on the machine itself that it started container
> > > getty and then stopped it.
> > > 
> > > It worked earlier so I am not sure what changed. No one on google 
> > > seems
> > > to have this specific error.
> > 
> > There is a patch which fixes this problem:
> > http://lists.freedesktop.org/archives/systemd-devel/2015
> > -February/028603.html
> > 
> > git log --grep tells me that is has been already commited as
> > f2273101c21bc59a390379e182e53cd4f07a7e71:
> > 
> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=f2273101c21bc59a
> > 390379e182e53cd4f07a7e71
> > 
> > 
> > Stay tuned,
> > Stefan
> 
> I still seem to have this issue with this. I am currently working on
> compiling upstream git of systemd so I can try running machined from
> there. Will let you know results.
> 
> Any specific tips for debugging it?
> 
> Regards,
> Jake
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

For reference, here is the output of systemd-machined if I set
SYSTEMD_LOG_LEVEL=debug

Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd[1]: Starting Virtual Machine 
and Container Registration Service...
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: 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
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Got message 
type=method_return sender=org.freedesktop.DBus destination=:1.636 object=n/a 
interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Sent 
message type=method_call sender=n/a destination=org.freedesktop.DBus 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch 
cookie=2 reply_cookie=0 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Sent 
message type=method_call sender=n/a destination=org.freedesktop.DBus 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch 
cookie=3 reply_cookie=0 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Sent 
message type=method_call sender=n/a destination=org.freedesktop.DBus 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch 
cookie=4 reply_cookie=0 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Sent 
message type=method_call sender=n/a destination=org.freedesktop.DBus 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch 
cookie=5 reply_cookie=0 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Sent 
message type=method_call sender=n/a destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=Subscribe cookie=6 reply_cookie=0 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Sent 
message type=method_call sender=n/a destination=org.freedesktop.DBus 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName 
cookie=7 reply_cookie=0 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Sent 
message type=method_call sender=n/a destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/nspawn_40gitbucket_2eservice 
interface=org.freedesktop.DBus.Properties member=Get cookie=8 reply_cookie=0 
error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd[1]: Started Virtual Machine 
and Container Registration Service.
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: New machine 
gitbucket.
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Sent 
message type=signal sender=n/a destination=n/a object=/org/freedesktop/machine1 
interface=org.freedesktop.machine1.Manager member=MachineNew cookie=9 
reply_cookie=0 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: 
systemd-machined running as pid 21619
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Got message 
type=signal sender=org.freedesktop.DBus destination=:1.636 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired 
cookie=2 reply_cookie=0 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com systemd-machined[21619]: Got message 
type=signal sender=org.freedesktop.DBus destination=:1.636 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired 
cookie=7 reply_cookie=0 error=n/a
Apr 17 15:08:42 jbrandeb-host.jf.intel.com

Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Cristian Rodríguez]

On Fri, Apr 17, 2015 at 4:06 PM, Matt Hoosier  wrote:
> On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering
>  wrote:
>>
>> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@gmail.com) wrote:
>>
>> > Hi,
>> >
>> > I'm writing to see whether there's a "best" way to allow systemd to
>> > inherit
>> > ownership of a process forked from a hand-crafted /sbin/init process
>> > before
>> > that hand-crafted process turns over the keys to systemd by doing
>> > exec("/lib/systemd/systemd") over the top of itself and allowing it to
>> > take
>> > over as PID 1.
>>
>> We support this only really for "kernel-like" processes that are
>> started from the initrd, and basically run as long as the system is up
>> without every being restarted in between, thus effectively appearing
>> much like a kernel process and nothing systemd should
>> manage. Processes like this should be marked with argv[0][0] = '@',
>> see for details:
>>
>> https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/
>>
>> > I know that sounds like an odd thing to ask about. The use-case has to
>> > do
>> > with being able to start some work extremely early during boot of
>> > embedded
>> > systems to achieve performance goals. I don't wish to subvert systemd,
>> > and
>> > in fact would love for systemd to be able to monitor the process, stop
>> > it,
>> > restart according to the normal [Service] configuration in a unit file
>> > describing the process.
>>
>> Hmm, are you sure that invoking the binary from systemd as first
>> service is really that much slower than starting systemd only afterwards?
>
>
> The bootcharting that I do seems to show that about 1.2 - 1.5 sec are spent
> internal to systemd before any external processes get run for the particular
> embedded CPU I'm using. That gap is a killer at the moment.

Did you watch this presentation ?

https://www.youtube.com/watch?v=RFVlbaDqll8

what part of systemd is taking 1.5 seconds to start, on what CPU and
how much of RAM does the board has ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Zombie process still exists after stopping gdm.service

[Daniel Drake]

Hi,

I'm investigating why "systemctl stop gdm; Xorg" usually fails. The
new X process complains that X is still running.

Here's what I think is happening:

1. systemd sends SIGTERM to gdm to stop the service

2. gdm exits - it has a simple SIGTERM handler which just quits the
mainloop without doing any cleanup (as far as I can see, it doesn't
make any attempt to kill the child X server)

3. X exits because of PR_SET_PDEATHSIG (i.e. it's set to be
automatically killed when the parent goes away). The killed process
enters defunct state and is reparented to PID 1, presumably also
moving it out of the gdm cgroup.

4. systemd notes that gdm's cgroup is empty and decides that gdm is
now successfully stopped.

5. systemctl returns and now Xorg is launched immediately. Xorg reads
the PID of the old Xorg process from /tmp, and notices that that PID
is still in use (it is still an unreaped zombie) because kill()
doesn't return an error. Xorg aborts thinking that it is already
running.

6. Moments later, systemd reaps the zombie. Oops, too late.


Does that make sense?
I wonder how it is best to fix this. Is it a bug that systemd decided
that gdm.service had stopped before it had reaped zombie processes
that originally belonged to gdm?

Is it a gdm bug that killing gdm doesn't make any attempt to reap X
before going away itself? (they chose PR_SET_PDEATHSIG to do something
similar, but maybe we have to argue that it is not quite sufficient)

Thanks
Daniel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Matt Hoosier]

On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering  wrote:

> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@gmail.com) wrote:
>
> > Hi,
> >
> > I'm writing to see whether there's a "best" way to allow systemd to
> inherit
> > ownership of a process forked from a hand-crafted /sbin/init process
> before
> > that hand-crafted process turns over the keys to systemd by doing
> > exec("/lib/systemd/systemd") over the top of itself and allowing it to
> take
> > over as PID 1.
>
> We support this only really for "kernel-like" processes that are
> started from the initrd, and basically run as long as the system is up
> without every being restarted in between, thus effectively appearing
> much like a kernel process and nothing systemd should
> manage. Processes like this should be marked with argv[0][0] = '@',
> see for details:
>
> https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/
>
> > I know that sounds like an odd thing to ask about. The use-case has to do
> > with being able to start some work extremely early during boot of
> embedded
> > systems to achieve performance goals. I don't wish to subvert systemd,
> and
> > in fact would love for systemd to be able to monitor the process, stop
> it,
> > restart according to the normal [Service] configuration in a unit file
> > describing the process.
>
> Hmm, are you sure that invoking the binary from systemd as first
> service is really that much slower than starting systemd only afterwards?
>

The bootcharting that I do seems to show that about 1.2 - 1.5 sec are spent
internal to systemd before any external processes get run for the
particular embedded CPU I'm using. That gap is a killer at the moment.

I'm sure this is quite the naive question, but: is there a simple option I
can insert into my "super-important" first service that would cause all
other units to be forestalled until my service reports that it's
initialized? I.e., something like:

[Unit]
DefaultDependencies=no
Before=very-first-normal-systemd-unit.service

I didn't have luck identifying such a
very-first-normal-systemd-unit.service on my own, but I'm admittedly rather
inexperienced poking around the internal default suite of units packaged
with systemd.


>
> > I can achieve a poor man's version of this right now by telling my
> > hand-spawned process to write out a pid file, and then supplying a unit
> > file that looks something like:
> >
> >   #foo.service
> >   [Unit]
> >   Description=Proxy unit file for foo run prior to systemd
> >   ...
> >
> >   [Service]
> >   Type=forking
> >   ExecStart=/bin/true
> >   PIDFile=/var/run/my-hand-forked-process-pidfile.txt
>
> urks, but yeah, this should work, however, this will not move the
> process into the service's cgroup. For that you can probably script
> something easily that echoes the PID manually into the cgroups dir of
> the service (which you can reference via %c).
>
> > This is at least enough to get my process into the overall dependency
> graph
> > and to allow other units to depend on the process nominally described by
> > foo.service. But any kind of use of the 'Restart' option is out of the
> > question using this approach. Similarly, 'systemctl start foo.service'
> > wouldn't be able to really start the service explicitly.
> >
> > Is there a (sneaky?) way to inform systemd that a daemon described
> property
> > in a service file, has already been launched and that systemd should
> simply
> > adopt the running instance?
>
> Not really. Maybe you can make the start routine of your daemon smart
> enough to check if the daemon is already up. If so, you move that
> process to the cgroup the routine is started in. If not you fork off
> the real daemon. That way, you can start the daemon before systemd,
> then systemd will start it again, but instead of forking off a new
> instance it would just adopt the existing instance by systemd. When
> the daemon is the restarted through systemd then it will terminate the
> daemon cleanly and the new forked of process will be a regular again,
> if you follow what I mean.
>

Fair enough. That approach had occurred to me also.


>
> But this is all ugly, this is really nothing we want to support
> officially I am sure...
>

Understood.


>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>

-Matt
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] machinectl login fails systemd 219

[Keller, Jacob E]

On Wed, 2015-04-15 at 00:07 +0200, Stefan Tatschner wrote:
> On Di, 2015-04-14 at 21:56 +, Keller, Jacob E wrote:
> > Failed to get machine PTY: Message did not receive a reply (timeout 
> > by message bus)
> > 
> > I get a notification on the machine itself that it started container
> > getty and then stopped it.
> > 
> > It worked earlier so I am not sure what changed. No one on google 
> > seems
> > to have this specific error.
> 
> There is a patch which fixes this problem:
> http://lists.freedesktop.org/archives/systemd-devel/2015
> -February/028603.html
> 
> git log --grep tells me that is has been already commited as
> f2273101c21bc59a390379e182e53cd4f07a7e71:
> 
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=f2273101c21bc59a
> 390379e182e53cd4f07a7e71
> 
> 
> Stay tuned,
> Stefan

I still seem to have this issue with this. I am currently working on
compiling upstream git of systemd so I can try running machined from
there. Will let you know results.

Any specific tips for debugging it?

Regards,
Jake
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] cryptsetup: Implement offset and skip options

[Martin Pitt]

Hello all,

Zbigniew Jędrzejewski-Szmek [2015-04-16 23:42 +]:
> Hm, I'd go even further and add a check:
> 
> if (arg_offset && arg_type != NULL && arg_type != CRYPT_PLAIN)
>   log_warning("offset= ignored with type %s", arg_type);
> if (arg_skip && arg_type != NULL && arg_type != CRYPT_PLAIN)
>   log_warning("skip= ignored with type %s", arg_type);
> 
> But patch looks fine without this too.

For the archives: Lennart reviewed that on the fd.o bug and pointed
out some other issues (adding to crypttab.5, and cleaner struct init).
This is in master now.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to get systemd boot messages on serial console and screen?

[Lennart Poettering]

On Fri, 17.04.15 13:57, Frank Steiner (fsteiner-ma...@bio.ifi.lmu.de) wrote:

> Lennart Poettering wrote
> 
> > We write the status output to /dev/console, see status_vprintf():
> > 
> > http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/terminal-util.c#n643
> > 
> > Usually the kernel will forward what is written to /dev/console to all
> > console= terminals listed on the kernel cmdline.
> > 
> > Check the contents of /sys/class/tty/console/active to see which
> > ttys those currently are.
> 
> I can see both (tty0 and ttyS4) there, but as far as I understand from
> reading the documentation /dev/console is always only connected to the
> last-specified console. Thus writing to /dev/console will only print
> to one console. See kernel/Documentation/serial-console.txt:
> 
> "You can specify multiple console= options on the kernel command line.
>  Output will appear on all of them. The last device will be used when
>  you open /dev/console. So, for example:
> 
> console=ttyS1,9600 console=tty0
> 
>  defines that opening /dev/console will get you the current foreground
>  virtual console, and kernel messages will appear on both the VGA
>  console and the 2nd serial port (ttyS1 or COM2) at 9600 baud."
> 
> That would exactly match what I see, i.e., kernel messages on both
> ttys, systemd always only on the last one.
> 
> I'm not sure how one can write to all consoles in parallel from user
> space, I think in SLES 11 blogd was used for this. It would be nice
> if systemd could print to all consoles without helper programs like
> plymouth etc.

Ah, sorry, yeah I was confused a bit. Indeed, /dev/console actually
will give you only the primary console tty.

The kernel's own logs will show up on all configured consoles
however. This is implemented in the kernel's kmsg subsystem which
pushes the kernel logs to all consoles. You can test this by echoing
something into /dev/kmsg, it should end up on all consoles as well as
the kernel log buffer.

However /dev/kmsg is not a tty, hence not really suitable for the
status output we do or even running a getty on...

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] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Lennart Poettering]

On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@gmail.com) wrote:

> Hi,
> 
> I'm writing to see whether there's a "best" way to allow systemd to inherit
> ownership of a process forked from a hand-crafted /sbin/init process before
> that hand-crafted process turns over the keys to systemd by doing
> exec("/lib/systemd/systemd") over the top of itself and allowing it to take
> over as PID 1.

We support this only really for "kernel-like" processes that are
started from the initrd, and basically run as long as the system is up
without every being restarted in between, thus effectively appearing
much like a kernel process and nothing systemd should
manage. Processes like this should be marked with argv[0][0] = '@',
see for details:

https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/

> I know that sounds like an odd thing to ask about. The use-case has to do
> with being able to start some work extremely early during boot of embedded
> systems to achieve performance goals. I don't wish to subvert systemd, and
> in fact would love for systemd to be able to monitor the process, stop it,
> restart according to the normal [Service] configuration in a unit file
> describing the process.

Hmm, are you sure that invoking the binary from systemd as first
service is really that much slower than starting systemd only afterwards?

> I can achieve a poor man's version of this right now by telling my
> hand-spawned process to write out a pid file, and then supplying a unit
> file that looks something like:
> 
>   #foo.service
>   [Unit]
>   Description=Proxy unit file for foo run prior to systemd
>   ...
> 
>   [Service]
>   Type=forking
>   ExecStart=/bin/true
>   PIDFile=/var/run/my-hand-forked-process-pidfile.txt

urks, but yeah, this should work, however, this will not move the
process into the service's cgroup. For that you can probably script
something easily that echoes the PID manually into the cgroups dir of
the service (which you can reference via %c). 

> This is at least enough to get my process into the overall dependency graph
> and to allow other units to depend on the process nominally described by
> foo.service. But any kind of use of the 'Restart' option is out of the
> question using this approach. Similarly, 'systemctl start foo.service'
> wouldn't be able to really start the service explicitly.
> 
> Is there a (sneaky?) way to inform systemd that a daemon described property
> in a service file, has already been launched and that systemd should simply
> adopt the running instance?

Not really. Maybe you can make the start routine of your daemon smart
enough to check if the daemon is already up. If so, you move that
process to the cgroup the routine is started in. If not you fork off
the real daemon. That way, you can start the daemon before systemd,
then systemd will start it again, but instead of forking off a new
instance it would just adopt the existing instance by systemd. When
the daemon is the restarted through systemd then it will terminate the
daemon cleanly and the new forked of process will be a regular again,
if you follow what I mean.

But this is all ugly, this is really nothing we want to support
officially I am sure...

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] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Zbigniew Jędrzejewski-Szmek]

On Fri, Apr 17, 2015 at 09:00:49AM -0500, Matt Hoosier wrote:
> Hi,
> 
> I'm writing to see whether there's a "best" way to allow systemd to inherit
> ownership of a process forked from a hand-crafted /sbin/init process before
> that hand-crafted process turns over the keys to systemd by doing
> exec("/lib/systemd/systemd") over the top of itself and allowing it to take
> over as PID 1.
> 
> I know that sounds like an odd thing to ask about. The use-case has to do
> with being able to start some work extremely early during boot of embedded
> systems to achieve performance goals. I don't wish to subvert systemd, and
> in fact would love for systemd to be able to monitor the process, stop it,
> restart according to the normal [Service] configuration in a unit file
> describing the process.
> 
> I can achieve a poor man's version of this right now by telling my
> hand-spawned process to write out a pid file, and then supplying a unit
> file that looks something like:
> 
>   #foo.service
>   [Unit]
>   Description=Proxy unit file for foo run prior to systemd
>   ...
> 
>   [Service]
>   Type=forking
>   ExecStart=/bin/true
>   PIDFile=/var/run/my-hand-forked-process-pidfile.txt
> 
> This is at least enough to get my process into the overall dependency graph
> and to allow other units to depend on the process nominally described by
> foo.service. But any kind of use of the 'Restart' option is out of the
> question using this approach. Similarly, 'systemctl start foo.service'
> wouldn't be able to really start the service explicitly.
> 
> Is there a (sneaky?) way to inform systemd that a daemon described property
> in a service file, has already been launched and that systemd should simply
> adopt the running instance?
See systemd.scope(5).

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[josh]

On Fri, Apr 17, 2015 at 06:00:04PM +0200, David Herrmann wrote:
> Hi
> 
> On Fri, Apr 17, 2015 at 5:52 PM, Josh Triplett  wrote:
> > On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote:
> >> Now, to put together a more complex scenario for you: consider a small
> >> web UI that can be used to set the system time. It should realy run at
> >> minimal privileges, after all it has a surface to the web. Hence you
> >> write it as daemon, make it run as a user id of its own, set up a
> >> chroot() or a file system namespace, but you do keep CAP_SYS_TIME and
> >> a bus connection open. With that setup the web daemon can pretty much
> >> only set the system clock, and if it exploited cannot be used for much
> >> else. It will not have access to /dev/rtc, due to the file system
> >> namespace, but it can nicely set the system clock via timedated still,
> >> and pretty much only that, and the clock will be synced to the RTC by
> >> it.
> >>
> >> To map this back to your earlier request for an example. In this case
> >> process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message
> >> C is the SetTime() bus call. Daemon D is timedated.
> >>
> >> If the web UI daemon would not have CAP_SYS_TIME it couldn't change
> >> the time like this -- unless of course that web UI daemon would run as
> >> UID 0 all the time, which is certainly much much less desirable, given
> >> that it is a network facing daemon.
> >
> > I agree with your statement that any process with the ability to do an
> > operation directly (bypassing systemd) should have the ability to do so
> > safely through systemd.  However, that doesn't provide a complete
> > solution, because the reverse shouldn't necessarily be true: it should
> > be possible to grant a process the ability to do an operation safely
> > through systemd *without* granting it permission to do so directly.
> >
> > For instance, a user's desktop session should have permission to shut
> > down the system politely by asking systemd to shut down, without having
> > permission to shut down the system impolitely by invoking the reboot
> > system call.  Or in your time service example, the admin may want to
> > grant the web service permission to set the clock via timedated, but
> > *not* directly via settimeofday.
> >
> > (I'm assuming below that you agree there should be a mechanism to offer
> > privileges to do a safe operation but *not* the corresponding unsafe
> > operation.  If you don't agree, let's talk about that first.)
> >
> > Given that, some mechanism needs to exist to grant the
> > safe-but-not-unsafe permissions.  That might be polkit, or something
> > like dbus bus policies, or some other mechanism.
> 
> This is _exactly_ what we do whenever it's a reasonable choice.

Glad to hear that.  With that mechanism in place, then, is the
capability-based check really necessary?  It's a nice convenience, that
avoids needing to explicitly use the new mechanism to grant permission
to an already privileged process, but it doesn't seem necessary.

Would it be that much of an imposition to push kdbus without capability
capturing first, and then argue for kdbus with capability capturing
later as a convenience feature?  As far as I can tell, that mechanism
can be added in a backward-compatible way, with older kernels just not
supporting it.

- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Another attempt: Making dependencies properly overridable

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote:
> Am 2015-02-16 14:16, schrieb Lennart Poettering:
> >On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote:
> >>Not quite. While you can use drop-in snippets to amend
> >>orderings/depends, it's (unfortunately) not possible to override
> >>Wants=,Before= etc.
> >
> >There have been discussions to allow masking deps via /dev/null
> >symlinks in .wants/ and .requires/ dirs... I think that'd be a better
> >solution...
> >[...]
> >>Agreed, systemctl edit is much nicer. Unfortunately, as said above,
> >>drop-ins can *not* be used to override all aspects of a native unit
> >>file. So it's not (yet) a complete replacement for insserv
> >>overrides.
> >>
> >>If it would be possible to unset Wants= or After=, just like other
> >>service properties, then things would be different.
> >
> >As mentioned, I'd be happy to take patches to make precisely that
> >work!
> 
> Last time I talked about this here, there was a lot of confusion, so
> I didn't pursue it further. But I would really like to get this to
> work, but before I start with a patch, I'd like to explain what I'd
> like to do before working on it, to see if it works for you.
> 
> The semantics I'd like to see would be the following:
> 
>  - anything in /etc named exactly the same as in /usr/lib overrides
>the latter, just as is already the case with units and drop-ins
> 
>  => allow masking of .wants/ and .requires/ with symlinks to
> /dev/null (I think you were in favor of that)
> 
>  - additionally, postpone processing of dependencies in unit files
>until the entire unit (and all drop-ins) have been read in
> 
>   For example, even without a drop-in:
> 
>   a.service:
>   [Unit]
>   Wants=b.service
>   Wants=
>   Wants=c.service
> 
>   After that, Wants should be set to c.service. Note that this
>   should NOT affect dependencies set in other ways, i.e. via
>   .wants/ directories or by dependencies of other services, this
>   should JUST alter what was specified in the unit itself.
> 
>   A more complex example to illustrate the latter:
> 
>   /usr/lib/.../a.service:
> [Unit]
> Wants=b.service
> After=c.service
> 
>   /usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service
>   /usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service
> 
>   /usr/lib/.../f.service
> [Unit]
> Before=a.service
> 
>   /etc/.../a.service.d/dont-depend-on-b.conf:
> [Unit]
> Wants=
> 
>   /etc/.../a.service.d/not-after-c.conf:
> [Unit]
> After=
> 
>   /etc/.../a.service.wants/e.service -> /dev/null
> 
>   In the end, the dependnecies should be:
> 
>  Wants=d.service
> - b.service gets removed via drop-in
> - e.service gets removed because it's masked
> - but d.service stays, because it was never defined in
>   the unit file, so a drop-in doesn't override it, only
>   the mask does
> 
>  After=f.service
> - c.service gets removed via drop-in
> - f.service is not declared in the original unit file but
>   rather in f.service as a Before= dependency, so you'd
>   have to override that to make this go into effect
> 
>  The general principle would be: you can drop stuff at the same
>  place it's defined. If it's defined as After= in a unit,
>  override it in a drop-in for that unit, if it's defined as
>  Before= in another unit, override it in a drop-in for the other
>  unit, and if it's defined in the filesystem via .wants/ or
>  .requires/, you can override it by masking it in the filesystem.
>  Only in the end will all remaining dependencies be combined to
>  make up the entire list of dependencies for that service.
> 
> Would you be agreeable to these semantics? If so, I'll hack up a
> patch.
Seems quite intuitive to me. Would be great to have this implemented.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Andy Lutomirski]

On Apr 17, 2015 4:53 AM, "Djalal Harouni"  wrote:
>
> Hi Andy,
>
> On Thu, Apr 16, 2015 at 12:30:28PM -0700, Andy Lutomirski wrote:
> > On Thu, Apr 16, 2015 at 11:23 AM, Lennart Poettering
> >  wrote:
> [...]
> > AFAICT this piece of kdbus code serves to enable a rather odd way to
> > write privilege-separated services to change the time and kill
> > processes.  The cost is complex security code that, at best, fails
> > secure in the presence of different user namespaces, and the cost also
> > involves touching a global refcount for each message sent (this might
> > be the *only* thing that would reference init_user_ns's refcount when
> > sending).  Oh yeah, the cost is also ABI crap -- if, say, my
> The global ref-counts on metadata is just a workaround due to userns and
> caps. I actually thought we already sorted that out?
>
>  https://lkml.org/lkml/2015/3/25/702
>
> Hmm there are other paths that refs user_ns, the mqueue notification
> perhaps ?
>
> Please note that we also have _per_ user quota accounting, the trade off
> of accouting prevents further performance penalties on other bus
> operations. Referring to performance critical code, this code path can
> just be ignored by to not opt-in for KDBUS_ATTACH_CAPS which is the
> default behaviour.

Quoting that link:

> It's conditional on KDBUS_ATTACH_CAPS, anyway.

Fair enough.

[end quote]

I don't believe it'll be usefully conditional.  Systemd is pretty
clearly planning on using it, so you get a silly, if small,
performance hit.

My point here is that there's no real shortage of downsides to this
scheme, and there still appears to be little to no benefit.

--Andy

>
> Thanks!
>
> --
> 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] SD_BUS_VTABLE_CAPABILITY

[Andy Lutomirski]

On Apr 17, 2015 5:42 AM, "Simon McVittie"
 wrote:
>
> On 16/04/15 15:52, Andy Lutomirski wrote:
> > (I really think this dichotomy
> > needs to be removed, *especially* since it looks like code already
> > exists to try to use both metadata sources.  This seems like it's just
> > asking for security screw-ups.)
>
> Would it address this concern if there was an explicit API separation
> into "things that can't be faked, suitable for authorization" and
> "things that could have been faked, only suitable for debugging" - such
> that the uid would be in the first set only, capabilities would be in
> the first set on kdbus but absent or in the second set on traditional
> D-Bus, and /proc/*/cmdline would always be in the second set?

It would certainly improve the sd-bus code, I think.  I'm not a
systemd developer, though.

From the kernel side, I don't even see the point of reporting caps for
debugging IPC things.

--Andy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Andy Lutomirski]

On Apr 17, 2015 6:05 AM, "Cristian Rodríguez"  wrote:
>
> On Fri, Apr 17, 2015 at 7:51 AM, Lennart Poettering
>  wrote:
>
> > Groups *suck* as authentication scheme. If you add one group for each
> > privilege you want, then you'll have a huge number of groups, and
> > that's hardly desirable. It's pretty close to being unmanagable with
> > user/group editors. Also, you can never take group membership away,
> > since users who once where members of group can create sgid binaries
> > which allows them to always return into that group forever.
>
> Not to mention, we are running out of system users and groups in
> distributions (if we didn't already) and some people want us to
> provide fixed UID/GID system users
> across distributions for clustering applications...this is a totally
> unworkable way forward.

I believe you're arguing that you think gids are a scarse resource, so
you want to save ~2 gids (certainly fewer than 64) by inventing a
whole new userspace authorization scheme using *caps* that doesn't
even solve the problem that you want to solve.

I'm not sure how this is supposed to justify anything.  Caps are
probably the single least scalable authorization mechanism you could
come up with.

--Andy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[David Herrmann]

Hi

On Fri, Apr 17, 2015 at 5:52 PM, Josh Triplett  wrote:
> On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote:
>> Now, to put together a more complex scenario for you: consider a small
>> web UI that can be used to set the system time. It should realy run at
>> minimal privileges, after all it has a surface to the web. Hence you
>> write it as daemon, make it run as a user id of its own, set up a
>> chroot() or a file system namespace, but you do keep CAP_SYS_TIME and
>> a bus connection open. With that setup the web daemon can pretty much
>> only set the system clock, and if it exploited cannot be used for much
>> else. It will not have access to /dev/rtc, due to the file system
>> namespace, but it can nicely set the system clock via timedated still,
>> and pretty much only that, and the clock will be synced to the RTC by
>> it.
>>
>> To map this back to your earlier request for an example. In this case
>> process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message
>> C is the SetTime() bus call. Daemon D is timedated.
>>
>> If the web UI daemon would not have CAP_SYS_TIME it couldn't change
>> the time like this -- unless of course that web UI daemon would run as
>> UID 0 all the time, which is certainly much much less desirable, given
>> that it is a network facing daemon.
>
> I agree with your statement that any process with the ability to do an
> operation directly (bypassing systemd) should have the ability to do so
> safely through systemd.  However, that doesn't provide a complete
> solution, because the reverse shouldn't necessarily be true: it should
> be possible to grant a process the ability to do an operation safely
> through systemd *without* granting it permission to do so directly.
>
> For instance, a user's desktop session should have permission to shut
> down the system politely by asking systemd to shut down, without having
> permission to shut down the system impolitely by invoking the reboot
> system call.  Or in your time service example, the admin may want to
> grant the web service permission to set the clock via timedated, but
> *not* directly via settimeofday.
>
> (I'm assuming below that you agree there should be a mechanism to offer
> privileges to do a safe operation but *not* the corresponding unsafe
> operation.  If you don't agree, let's talk about that first.)
>
> Given that, some mechanism needs to exist to grant the
> safe-but-not-unsafe permissions.  That might be polkit, or something
> like dbus bus policies, or some other mechanism.

This is _exactly_ what we do whenever it's a reasonable choice.

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Josh Triplett]

On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote:
> Now, to put together a more complex scenario for you: consider a small
> web UI that can be used to set the system time. It should realy run at
> minimal privileges, after all it has a surface to the web. Hence you
> write it as daemon, make it run as a user id of its own, set up a
> chroot() or a file system namespace, but you do keep CAP_SYS_TIME and
> a bus connection open. With that setup the web daemon can pretty much
> only set the system clock, and if it exploited cannot be used for much
> else. It will not have access to /dev/rtc, due to the file system
> namespace, but it can nicely set the system clock via timedated still,
> and pretty much only that, and the clock will be synced to the RTC by
> it.
> 
> To map this back to your earlier request for an example. In this case
> process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message
> C is the SetTime() bus call. Daemon D is timedated. 
> 
> If the web UI daemon would not have CAP_SYS_TIME it couldn't change
> the time like this -- unless of course that web UI daemon would run as
> UID 0 all the time, which is certainly much much less desirable, given
> that it is a network facing daemon.

I agree with your statement that any process with the ability to do an
operation directly (bypassing systemd) should have the ability to do so
safely through systemd.  However, that doesn't provide a complete
solution, because the reverse shouldn't necessarily be true: it should
be possible to grant a process the ability to do an operation safely
through systemd *without* granting it permission to do so directly.

For instance, a user's desktop session should have permission to shut
down the system politely by asking systemd to shut down, without having
permission to shut down the system impolitely by invoking the reboot
system call.  Or in your time service example, the admin may want to
grant the web service permission to set the clock via timedated, but
*not* directly via settimeofday.

(I'm assuming below that you agree there should be a mechanism to offer
privileges to do a safe operation but *not* the corresponding unsafe
operation.  If you don't agree, let's talk about that first.)

Given that, some mechanism needs to exist to grant the
safe-but-not-unsafe permissions.  That might be polkit, or something
like dbus bus policies, or some other mechanism.

Now, I can still see the value in saying "if you have permission to do
the unsafe thing directly, you can do the safe thing".  However, that
seems like an optional enhancement, rather than core required
functionality to make sane use of (k)dbus.  kdbus without the
capability-passing mechanism still seems like a wildly useful
enhancement.

Based on that, I'm wondering if there's any fundamental reason not to
split that out as a separate patch, get the remaining less-controversial
parts of kdbus merged, and then make the case for that separately.  Then
kdbus would be available for everyone to use sooner, and later on it
could gain some additional features.

- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v4 3/4] hwdb: Add entries for the trackpoint on 2 Thinkpads

[Hans de Goede]

Lenovo has changed the sensitivity of the trackpoint on the x240 / T440s / T540
generation of Thinkpads, making them somewhat insensitive by default, add a
hwdb entry to tweak the sensitivity setting.

The ThinkPad X200s is way way too slow by default and unless you push the
trackpoint quite hard only sends delta events in the 1-2 range, tweak the
sensitivity to make it send a wider range of deltas and apply a const accel
factor to make it have a more reasonable speed by default.
---
 hwdb/70-pointingstick.hwdb | 17 +
 1 file changed, 17 insertions(+)

diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
index c5bd92d..c79602e 100644
--- a/hwdb/70-pointingstick.hwdb
+++ b/hwdb/70-pointingstick.hwdb
@@ -68,3 +68,20 @@
 
 #
 # Sort by by brand, model
+
+#
+# Lenovo
+#
+
+# Lenovo Thinkpad X200s / X201s
+# Note these come with 2 revisions of keyboard, with the trackpoints having a
+# different sensitivity in the different revisions. 1.25 is a bit slow for the
+# least sensitive revision, but it is better to be a bit slow then too fast.
+evdev:name:TPPS/2 IBM 
TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX20?s:*
+  POINTINGSTICK_SENSITIVITY=200
+  POINTINGSTICK_CONST_ACCEL=1.25
+
+# Lenovo Thinkpad T440s
+evdev:name:TPPS/2 IBM 
TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT440s:*
+  POINTINGSTICK_SENSITIVITY=200
+  POINTINGSTICK_CONST_ACCEL=1.0
-- 
2.3.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v4 1/4] udev: Add hwdb file for setting pointingstick properties

[Hans de Goede]

There is quite a wide spread in the delta events generated by pointingsticks,
some generate deltas of 1-2 under normal use, while others generate deltas
from 1-20.

This commit adds a hwdb file which allows specifying a per model
POINTINGSTICK_CONST_ACCEL value which can be used by the userspace input stack
to normalize the deltas so that all pointingsticks get the same feeling ootb.

The hwdb matching re-uses the existing 60-evdev.rules.
---
 hwdb/70-pointingstick.hwdb | 58 ++
 1 file changed, 58 insertions(+)
 create mode 100644 hwdb/70-pointingstick.hwdb

diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
new file mode 100644
index 000..8241181
--- /dev/null
+++ b/hwdb/70-pointingstick.hwdb
@@ -0,0 +1,58 @@
+# This file is part of systemd.
+#
+# Pointingstick const-accel configuration, to make different brand / model
+# laptop pointingsticks have the same speed / feel, and per model adjustment
+# of the IBM TrackPoint driver's sensitivty setting
+#
+# The lookup keys are composed in:
+#   60-evdev.rules
+#
+# Note: The format of the "evdev:" prefix match key is a contract between the
+# rules file and the hardware data, it might change in later revisions to
+# support more or better matches, it is not necessarily a stable ABI.
+#
+# Supported hardware matches are:
+#  - Generic input devices match:
+#  evdev:input:bvpe-
+#This matches on the kernel modalias of the input-device, mainly:
+# is the bus-id (see /usr/include/linux/input.h BUS_*), ,  and
+#WWW are the 4-digit hex uppercase vendor, product and version ID and 
+#is an arbitrary length input-modalias describing the device capabilities.
+#
+#  - Input driver device name and DMI data match:
+#  evdev:name::dmi:bvn*:bvr*:bd*:svn:pn*
+# is the name device specified by the driver,
+# is the firmware-provided string from the kernel DMI modalias.
+#
+# To add local entries, create a new file
+#   /etc/udev/hwdb.d/71-pointingstick-local.hwdb
+# and add your rules there. To load the new rules execute (as root):
+#   udevadm hwdb --update
+#   udevadm trigger /dev/input/eventXX
+# where /dev/input/eventXX is the pointingstick in question. If in
+# doubt, simply use /dev/input/event* to reload all input rules.
+#
+# If your changes are generally applicable, open a bug report on
+#   http://bugs.freedesktop.org/enter_bug.cgi?product=systemd
+# and include your new rules, a description of the device, and the
+# output of
+#   udevadm info /dev/input/eventXX
+# (or /dev/input/event*).
+#
+# Allowed properties are:
+#   POINTINGSTICK_CONST_ACCEL
+#
+#
+#  POINTINGSTICK_CONST_ACCEL#
+#
+#
+# Trackpoint const accel settings are specified as
+#POINTINGSTICK_CONST_ACCEL=
+#
+# Where  is a floating point number, using a '.' seperator, specifying
+# by how much to multiply deltas generated by the pointingstick to get
+# normalized deltas.
+#
+
+#
+# Sort by by brand, model
-- 
2.3.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v4 2/4] udev: keyboard-builtin: Add support for setting IBM trackpoint sensitivity

[Hans de Goede]

IBM / Lenovo trackpoints allow specifying a sensitivity setting through a
ps/2 command, which changes the range of the deltas sent when using the
trackpoint.

On some models with normal usage only deltas of 1 or 2 are send, resulting in
there only being 2 mouse cursor movement speeds, rather than the expected fluid
scale. Changing the sensitivity to a higher level than the bootup default fixes
this.

This commit adds support for setting a POINTINGSTICK_SENSITIVITY value
in hwdb to allow changing the sensitivity on boot through udev / hwdb.
---
 hwdb/70-pointingstick.hwdb   | 12 
 src/udev/udev-builtin-keyboard.c | 28 
 2 files changed, 40 insertions(+)

diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
index 8241181..c5bd92d 100644
--- a/hwdb/70-pointingstick.hwdb
+++ b/hwdb/70-pointingstick.hwdb
@@ -41,6 +41,7 @@
 #
 # Allowed properties are:
 #   POINTINGSTICK_CONST_ACCEL
+#   POINTINGSTICK_SENSITIVITY
 #
 #
 #  POINTINGSTICK_CONST_ACCEL#
@@ -53,6 +54,17 @@
 # by how much to multiply deltas generated by the pointingstick to get
 # normalized deltas.
 #
+#
+#  POINTINGSTICK_SENSITIVITY#
+#
+#
+# TPPS/2 IBM TrackPoint driver sensitivity sysfs setting
+#POINTINGSTICK_SENSITIVITY=
+#
+# Where  is a number between 0 and 255, note this property
+# only applies to TPPS/2 IBM TrackPoint devices, see
+# drivers/input/mouse/trackpoint.c in the Linux kernel sources.
+#
 
 #
 # Sort by by brand, model
diff --git a/src/udev/udev-builtin-keyboard.c b/src/udev/udev-builtin-keyboard.c
index c7f7f84..e8cc4b8 100644
--- a/src/udev/udev-builtin-keyboard.c
+++ b/src/udev/udev-builtin-keyboard.c
@@ -146,6 +146,32 @@ static void override_abs(int fd, const char *devnode,
 log_error_errno(errno, "Unable to EVIOCSABS device \"%s\"", 
devnode);
 }
 
+static void set_trackpoint_sensitivity(struct udev_device *dev, const char 
*value)
+{
+struct udev_device *pdev;
+char val_s[DECIMAL_STR_MAX(int) + 1];
+int r, val_i;
+
+/* The sensitivity sysfs attr belongs to the serio parent device */
+pdev = udev_device_get_parent_with_subsystem_devtype(dev, "serio", 
NULL);
+if (!pdev) {
+log_error("Failed to get serio parent for '%s'", 
udev_device_get_devnode(dev));
+return;
+}
+
+r = safe_atoi(value, &val_i);
+if (r < 0) {
+log_error("Unable to parse POINTINGSTICK_SENSITIVITY '%s' for 
'%s'", value, udev_device_get_devnode(dev));
+return;
+}
+
+xsprintf(val_s, "%d", val_i);
+
+r = udev_device_set_sysattr_value(pdev, "sensitivity", val_s);
+if (r < 0)
+log_error_errno(r, "Failed to write 'sensitivity' attribute 
for '%s': %m", udev_device_get_devnode(pdev));
+}
+
 static int open_device(const char *devnode) {
 int fd;
 
@@ -223,6 +249,8 @@ static int builtin_keyboard(struct udev_device *dev, int 
argc, char *argv[], boo
 }
 
 override_abs(fd, node, evcode, 
udev_list_entry_get_value(entry));
+} else if (streq(key, "POINTINGSTICK_SENSITIVITY")) {
+set_trackpoint_sensitivity(dev, 
udev_list_entry_get_value(entry));
 }
 }
 
-- 
2.3.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v4 4/4] hwdb: Add entries for the pointingstick on 2 Dell Latitudes

[Hans de Goede]

The pointingstick of the Dell Latitude E6400 is somewhat slow by default,
whereas the pointingstick of the Dell Latitude D620 is much too fast by
default, set POINTINGSTICK_CONST_ACCEL for both of them to adjust for this.
---
 hwdb/70-pointingstick.hwdb | 12 
 1 file changed, 12 insertions(+)

diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
index c79602e..9f922fd 100644
--- a/hwdb/70-pointingstick.hwdb
+++ b/hwdb/70-pointingstick.hwdb
@@ -70,6 +70,18 @@
 # Sort by by brand, model
 
 #
+# Dell
+#
+
+# Latitude D620
+evdev:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeD620*:pvr*
+  POINTINGSTICK_CONST_ACCEL=0.5
+
+# Latitude E6400
+evdev:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE6400*:pvr*
+  POINTINGSTICK_CONST_ACCEL=1.5
+
+#
 # Lenovo
 #
 
-- 
2.3.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v4 0/4] udev: Add builtin and hwdb files for setting pointingstick properties

[Hans de Goede]

Hi All,

Here is v4 of my pointstick set.

Changes since v3:
-Use the existing evdev matching rules
-Make setting the sensitivity part of the evdev builtin (which is called
 keyboard for historical reasons)

Changes since v2:
-Fix numerous spelling / gramatical errors in commit messages
-Add a reference to the kernel sources for the ibm trackpoint sensitivity
 setting

Changes since v1:
-Drop the patch to set ID_INPUT_TRACKPOINT, Peter already send almost the
 same patch to set ID_INPUT_POINTINGSTICK
-s/trackpoint/pointingstick/ unlike trackpoint pointingstick is a vendor
 neutral name, and pointingstick is also what the prop bit is called in
 linux/input.h Note that a few occurences where not replaced, as those refer
 specifically to IBM/Lenovo trackpoints
-Use ATTR{foo}= to assign sysfs attr value rather then spawning /bin/sh
-Dropped S-o-b from the commit messages

Regards,

Hans
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Matt Hoosier]

Hi,

I'm writing to see whether there's a "best" way to allow systemd to inherit
ownership of a process forked from a hand-crafted /sbin/init process before
that hand-crafted process turns over the keys to systemd by doing
exec("/lib/systemd/systemd") over the top of itself and allowing it to take
over as PID 1.

I know that sounds like an odd thing to ask about. The use-case has to do
with being able to start some work extremely early during boot of embedded
systems to achieve performance goals. I don't wish to subvert systemd, and
in fact would love for systemd to be able to monitor the process, stop it,
restart according to the normal [Service] configuration in a unit file
describing the process.

I can achieve a poor man's version of this right now by telling my
hand-spawned process to write out a pid file, and then supplying a unit
file that looks something like:

  #foo.service
  [Unit]
  Description=Proxy unit file for foo run prior to systemd
  ...

  [Service]
  Type=forking
  ExecStart=/bin/true
  PIDFile=/var/run/my-hand-forked-process-pidfile.txt

This is at least enough to get my process into the overall dependency graph
and to allow other units to depend on the process nominally described by
foo.service. But any kind of use of the 'Restart' option is out of the
question using this approach. Similarly, 'systemctl start foo.service'
wouldn't be able to really start the service explicitly.

Is there a (sneaky?) way to inform systemd that a daemon described property
in a service file, has already been launched and that systemd should simply
adopt the running instance?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Cristian Rodríguez]

On Fri, Apr 17, 2015 at 7:51 AM, Lennart Poettering
 wrote:

> Groups *suck* as authentication scheme. If you add one group for each
> privilege you want, then you'll have a huge number of groups, and
> that's hardly desirable. It's pretty close to being unmanagable with
> user/group editors. Also, you can never take group membership away,
> since users who once where members of group can create sgid binaries
> which allows them to always return into that group forever.

Not to mention, we are running out of system users and groups in
distributions (if we didn't already) and some people want us to
provide fixed UID/GID system users
across distributions for clustering applications...this is a totally
unworkable way forward.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Simon McVittie]

On 16/04/15 15:52, Andy Lutomirski wrote:
> (I really think this dichotomy
> needs to be removed, *especially* since it looks like code already
> exists to try to use both metadata sources.  This seems like it's just
> asking for security screw-ups.)

Would it address this concern if there was an explicit API separation
into "things that can't be faked, suitable for authorization" and
"things that could have been faked, only suitable for debugging" - such
that the uid would be in the first set only, capabilities would be in
the first set on kdbus but absent or in the second set on traditional
D-Bus, and /proc/*/cmdline would always be in the second set?

That's effectively what dbus-daemon has internally: for each
DBusConnection (which in practice wraps an AF_UNIX socket), it tracks
the uid, the pid, and in recent versions the LSM label (all taken from
getsockopt results), and a "log info" string (derived from /proc/$pid).

The "log info" is mentioned in the syslog message when something is
denied, but is not used for authentication, and is not made available to
dbus-daemon's clients such as polkit.

-- 
Simon McVittie
Collabora Ltd. 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to get systemd boot messages on serial console and screen?

[Frank Steiner]

Lennart Poettering wrote

> We write the status output to /dev/console, see status_vprintf():
> 
> http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/terminal-util.c#n643
> 
> Usually the kernel will forward what is written to /dev/console to all
> console= terminals listed on the kernel cmdline.
> 
> Check the contents of /sys/class/tty/console/active to see which
> ttys those currently are.

I can see both (tty0 and ttyS4) there, but as far as I understand from
reading the documentation /dev/console is always only connected to the
last-specified console. Thus writing to /dev/console will only print
to one console. See kernel/Documentation/serial-console.txt:

"You can specify multiple console= options on the kernel command line.
 Output will appear on all of them. The last device will be used when
 you open /dev/console. So, for example:

console=ttyS1,9600 console=tty0

 defines that opening /dev/console will get you the current foreground
 virtual console, and kernel messages will appear on both the VGA
 console and the 2nd serial port (ttyS1 or COM2) at 9600 baud."

That would exactly match what I see, i.e., kernel messages on both
ttys, systemd always only on the last one.

I'm not sure how one can write to all consoles in parallel from user
space, I think in SLES 11 blogd was used for this. It would be nice
if systemd could print to all consoles without helper programs like
plymouth etc.

cu,
Frank


-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. BioinformatikMail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17   Phone: +49 89 2180-4049
80333 Muenchen, Germany   Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Djalal Harouni]

Hi Andy,

On Thu, Apr 16, 2015 at 12:30:28PM -0700, Andy Lutomirski wrote:
> On Thu, Apr 16, 2015 at 11:23 AM, Lennart Poettering
>  wrote:
[...]
> AFAICT this piece of kdbus code serves to enable a rather odd way to
> write privilege-separated services to change the time and kill
> processes.  The cost is complex security code that, at best, fails
> secure in the presence of different user namespaces, and the cost also
> involves touching a global refcount for each message sent (this might
> be the *only* thing that would reference init_user_ns's refcount when
> sending).  Oh yeah, the cost is also ABI crap -- if, say, my
The global ref-counts on metadata is just a workaround due to userns and
caps. I actually thought we already sorted that out?

 https://lkml.org/lkml/2015/3/25/702

Hmm there are other paths that refs user_ns, the mqueue notification
perhaps ?

Please note that we also have _per_ user quota accounting, the trade off
of accouting prevents further performance penalties on other bus
operations. Referring to performance critical code, this code path can
just be ignored by to not opt-in for KDBUS_ATTACH_CAPS which is the
default behaviour.

Thanks!

-- 
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] udev interface naming for SR-IOV VFs

[Nir Soffer]

On Tue, Apr 14, 2015 at 1:11 PM, Ido Barkan  wrote:
> We are implementing support for SR-IOV network cards. Afer the changing of
> the number of VFs on the card and programmatically querying for all links
> (we use libnl for this) we observe that *during the iteration* over the links
> some of them were renamed by udev and still were not. Meanning, some of them
> are called 'ethN' and some are called 'enp2sNf2' (where N is an arbitrary
> number). Also, there are times that not all of the devices are returned from
> libnl.
> After a _while_ everything stabilizes (# of interfaces and names).
>
> My questions:
> 1. Is this what you would expect from udev? Meaning, this is just
>async behavior?

Generally yes. You can investigate that by monitoring udev events.

One way is to use udevadm monitor:

1. Start the monitor:

udevadm monitor --udev --property

2. Configure the SR-IOV card

3. Watch the events - you can use the timestamp to tell how much time it
   took until the new interfaces are ready.

Another way is to turn on debug level, and watch the system log.

1. Set log level to debug:

udevadm control --log-priority=debug

2. Start to watch the log in another shell

journalctl -f

3. Setup the SR-IOV card

> 2. Is there a way to _know_ programmticaly that everything was probed
>and renamed?  Not a heuristic?

Using udevadm settle, you can wait until the current events are handled,
but there are some issues:

- You don't know when events from the kernel are starting - while you
  wait for the SR-IOV modification (e.g, write to sysfs attribute), or
  after a while, and if all of them are triggered one after another, or
  after some delay. So udevadm settle may return before the devices are
  ready.

- It may be possible that one event will synthesize another event, so
  udev settle may return just before another event is triggered.

- You may wait for unrelated events that happen to trigger in the same
  time, waiting after the new interfaces are ready.

I think you need something like:

while True:
try:
udevadm.settle(1)
except udevadm.Timeout:
pass
else:
if all devices are ready:
break
time.sleep(1)

Note that it is not possible to detect a timeout in udevadm settle,
see http://lists.freedesktop.org/archives/systemd-devel/2015-April/030391.html

Nir
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Lennart Poettering]

On Thu, 16.04.15 12:30, Andy Lutomirski (l...@amacapital.net) wrote:

> > systemd itself checks CAP_SYS_KILL for clients asking to kill
> > arbitrary services (which means invoking kill() to all PIDs in the
> > service's cgroup).
> >
> > Similar to this, logind checks CAP_SYS_KILL for clients asking to kill
> > sessions (which means invoking kill() for all PIDS in the session).
> >
> 
> These aren't the kinds of examples I'm asking about.  They're what
> systemd does, not what use case makes doing that serve a purpose..
> 
> > Now, to put together a more complex scenario for you: consider a small
> > web UI that can be used to set the system time. It should realy run at
> > minimal privileges, after all it has a surface to the web. Hence you
> > write it as daemon, make it run as a user id of its own, set up a
> > chroot() or a file system namespace, but you do keep CAP_SYS_TIME and
> > a bus connection open.
> 
> Aha, a real example!
> 
> But this is a bad example -- systemd should provide the web server
> with a way to retain the right to issue the one method call that it
> needs.  CAP_SYS_TIME is overbroad.  

systemd or kdbus are not about inventing a completely new
authorization schemes. 

I mean, there are a thousand ways to lock things down. You can also
use SELinux or AppArmor here. But you can also use caps. And caps are
actually pretty nice for this, since a good scheme for a daemon like
this might be to first try the bus service if it is around, and as a
fallback go directly to the kernel. in that scheme it could then
support systemd and non-systemd systems, with pretty much the same
effect, without shipping things with completely different policies.

> For example, CAP_SYS_TIME also
> grants the service to bypass whatever auditing and logging systemd
> would do.

Sure, you can always argue that capabilities are broad, and that
something more fine-grained would be better. And I will absolutely
agree with you on this.

However, this is not about comparing caps with seccomp or selinux or
something like this. It's about granting that web ui daemon full root
privs with uid=0 vs. just CAP_SYS_TIME. And yes, just requiring the
cap is a ton safer than requiring full uid=0. And that's where the
core of the issue is!

I mean, yes, locking things down as much as possible is a great
thing. We can stack seccomp, apparmor, selinux, namespacing, uid
droppping all at the same time and then we have the safest system
ever. However, that doesn't relieve us from also saying that "yes,
caps are mor minimal than uid=0", and hence supporting caps instead of
just uid=0 as privilege indication.

> And this is also a worthless design pattern, as it seems to be
> applicable to sending signals and changing the time, and probably very
> little else.

Well, an accounting daemon that opens up acct() calls could use
CAP_SYS_PACCT.

Some debugging daemon that opens up controleld access to /dev/kmem or
so, could use CAP_SYS_RAWIO...

systemd itself could probably bind the resource management controls to
CAP_SYS_REOURCE.

Networkd can require CAP_NET_ADMIN for its config commands, and so on.

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] udevd: fix synchronization with settle when handling inotify events

[David Herrmann]

Hi

On Mon, Apr 13, 2015 at 4:49 PM, Daniel Drake  wrote:
> On Sat, Apr 11, 2015 at 5:13 AM, David Herrmann  wrote:
>> Nice catch!
>>
>> There's indeed a small race between handling inotify and queuing up
>> the change-event. We need to re-loop there. One day we should switch
>> to sd-event to avoid such bugs... I mean the symptom is inherent to
>> queuing up events while handling them. Meh!
>
> Thanks for reviewing this. Reading your comment, I wonder if there is
> a small bug in the solution here.
>
> Sometimes we may handle inotify events, but without generating change
> events. After my change, we will loop again, but there may be no
> events pending, in which case we will block on the 3 second timeout
> before completing the next loop iteration and replying to settle's
> ping message.

Not really. If a ctrl-message is pending, it will still be pending on
the next iteration, and thus immediately wake up the epoll_wait().
We're level-triggered here, not edge triggered! Hence, as long as we
didn't dispatch the ctrl-message, it's still pending and keep us
awake.

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] controlling serial console using a token

[Lennart Poettering]

On Fri, 17.04.15 15:54, Praveen kumar R (praveenrgo...@gmail.com) wrote:

> I have a token passed on by command line argument on which I need to decide
> to start the serial

On which command line? Kernel command line? What kind of "token"?

> console or not. I plan to tweak the getty*ttyS0.service and add the
> script which validates the token and starts the console.
> 
> Is this the right approach or is there any better way of handling it ??

To get a login getty on the serial port its sufficient to add
console=ttyS0... to the kernel cmdline. systemd automatically starts a
serial getty automatically on the first terminal the kernel console is
pointing to.

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] SD_BUS_VTABLE_CAPABILITY

[Lennart Poettering]

On Thu, 16.04.15 12:45, Cameron Norman (camerontnor...@gmail.com) wrote:

> On Thu, Apr 16, 2015 at 9:43 AM, Tom Gundersen  wrote:
> > On Thu, Apr 16, 2015 at 4:52 PM, Andy Lutomirski  
> > wrote:
> >> The ratio of complexity of capability code the kdbus folks have
> >> already written (hundreds of lines across multiple files) to its
> >> utility (very near zero AFAICT) is, in my book, not a good sign at
> >> all.
> >
> > We have several uses of this, see my mail to Jiri regarding
> > CAP_SYS_BOOT for instance:
> >   https://lkml.org/lkml/2015/4/16/219
> >
> 
> This could easily be done with polkit and a special `boot` group. Why
> does it need to use CAP_SYS_BOOT? I mean why would you even *want*
> CAP_SYS_BOOT to be used for this? Using CAP_SYS_BOOT means that
> anything you want to let cleanly shutdown the system you would also
> allow to do a hard shutdown and thus cause data loss in many cases.
> 
> In summary: not **necessary** or **ideal** to use a capability in
> this case.

Well, I believe it is certainly a good idea to protect the same
operations with the same privileges, instead of inventing new
privileges for everything, or littering the system with numerous unix
groups. I also believe that if you possess the privilege for the
dangerous operation you should also have the privilege for the safer
alternative.

Anyway, nothing is "necessary", nothing is "ideal". I mean, have a
multi-user OS is not "necessary", you can also decide to just trust
everybody. You can also decide that today's Linux is "good
enough". And you are probably right.

However, it's not about being "necessary" or "ideal". It's about being
*desirable*. And yes, I believe that strongly: it simplifies the
permission model quite substantially, as kernel and userspace agree on
the same privileges for the same operations. And it allows good
lockdown as shown in examples in this thread.

> If you could be so kind, could you summarize the other uses you have?
> And if you can, explain why using regular user/group credentials does
> not achieve the goal.

Groups *suck* as authentication scheme. If you add one group for each
privilege you want, then you'll have a huge number of groups, and
that's hardly desirable. It's pretty close to being unmanagable with
user/group editors. Also, you can never take group membership away,
since users who once where members of group can create sgid binaries
which allows them to always return into that group forever.

Do not misuse UNIX groups as way to express large amounts of
privileges. THis cannot fly.

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] SD_BUS_VTABLE_CAPABILITY

[Lennart Poettering]

On Thu, 16.04.15 12:52, Cameron Norman (camerontnor...@gmail.com) wrote:

> > It's easy to construct similar examples, for example for timedated,
> > where setting the system clock is subject to CAP_SYS_TIME, exactly
> > like the underlying system call. Using timedated instead of the system
> > call gives you the benefit of syncing things into RTC and some tohers,
> > but ultimately it's all about the system clock and should hence be
> > protected by the same privilege as the actual system call. Protecting
> > the "unsafe" raw system call with fewer privileges than the "safer"
> > path through timedated is certainly wrong and the other way round
> > to. It should really use the same privs!
> 
> As Andy said about the CAP_SYS_BOOT usage, they should NOT use the
> same credential.

Well, an explanation why not would be good. 

> Setting the raw clock is different from setting the system time
> through timedated, and should use different credentials.

Well, sure, it's different. But it's ultimately the same operation.
And again: allowing the dangerous operation to people with lesser
privileges but to require more privileges for the safer operation is
simply bogus.

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] CAD often useless

[Lennart Poettering]

On Fri, 17.04.15 03:29, Felix Miata (mrma...@earthlink.net) wrote:

> > When you see this message, then systemd will not bother with shuttding
> > down daemons cleanly anymore. However, it will still unmount all file
> > systems and sync things do disk. It will also pass control back to the
> > initrd,
> 
> So if initrd is deleted or rebuilt for the running kernel, shut down normally
> is not possible?

The initrd that is used for booting is kept around to make such
shutdowns possible cleanly, even if you update the kernel in between.

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] CAD often useless

[Lennart Poettering]

On Fri, 17.04.15 02:25, Felix Miata (mrma...@earthlink.net) wrote:

> Lennart Poettering composed on 2015-04-16 12:16 (UTC+0200):
> 
> > Felix Miata wrote:
> 
> >> Zbigniew Jędrzejewski-Szmek composed on 2015-04-15 18:11 (UTC):
> 
> >> > On Wed, Apr 15, 2015 at 13:31:38 -0400, Felix Miata wrote:
> 
> >> >> This isn't the first time or the only system. This particular one is an 
> >> >> old
> >> >> Athlon booted to F22 just updated last night. In order to try some 
> >> >> follow-up
> >> >> on a bug, I booted with drm.debug=14 log_buf_len=16M on cmdline. Somehow
> >> >> after exiting IceWM back into KDM, the system quit responding. After 
> >> >> some
> >> >> waiting, I was switched to a tty full of systemd-journal failed to write
> >> >> readonly filesystem messages. How the system got / into a readonly 
> >> >> state I
> >> >> have no idea, but my complaint is $SUBJECT, the time it takes, or the
> >> >> complete failure, trying to reboot when there is a problem, often seeing
> >> >> failed to store sound card state or failing boot *start* jobs. Why has
> >> >> rebooting to get out of trouble gotten to be so nearly impossible?
> 
> >> > Did you try to press CAD more than 7 times within 2s? This should
> >> > result in immedate reboot.
> 
> I don't normally count, but what I usually do is just hold the three keys
> down until the reboot process becomes apparent.

Also, let me add, that tHis is a bad idea. THis will queue additional
boot requests each time. THis is effectively coalesced in the state
engine, but you will possibly get confused logs, including audit and
utmp reboot records and suchlike.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] controlling serial console using a token

[Praveen kumar R]

I have a token passed on by command line argument on which I need to decide
to start the serial

console or not. I plan to tweak the getty*ttyS0.service and add the script
which validates the token

and starts the console.

Is this the right approach or is there any better way of handling it ??


Thanks,

Praveen R
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] black screen on startx exit

[Felix Miata]

Lennart Poettering composed on 2015-04-16 12:40 (UTC+0200):

> Felix Miata wrote:

>> I asked the following on freedesktop list a month ago and got no response. As
>> there was quite some time between this showing up in Fedora and Tumbleweed,
>> and Tumbleweed only lately upgraded systemd from 210 to 219, it looks like
>> systemd could be playing at least some part in this.

>> I first noticed this last May on rv200 and filed a Redhat bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1096487

>> Later it happened with Nouveau NV11 and I updated that bug.

>> Still later I noticed it happen on Cauldron on rv200:
>> https://ml.mageia.org/l/arc/dev/2014-09/msg00218.html

>> By last month it was happening in Tumbleweed on NV11.

>> So this doesn't look like any problem specific to the distros, but I don't
>> see any existing bug on bugs.freedesktop.org either. Could this be a problem
>> in something else, systemd or pam maybe? I've not seen this on Intel as old
>> as 845G? Would it actually be two bugs, one against Nouveau and another
>> against Radeon? Has no one else here encountered this?

> I do no see how this is related to systemd in any way.

I thought it possible. I don't understand what dependencies if any Xorg may
have on systemd, and saw an apparent time connection between upgrade to 219
and problem appearance in Tumbleweed.

> Please ask the X11/drivers people for help,

http://lists.x.org/archives/xorg/2015-March/057252.html got no response. A
follow-up attempt is at http://lists.x.org/archives/xorg/2015-April/057314.html

> or even better your distro maintainers.

That's what the links in my OP were about. The bugzilla.redhat.com bug has
generated no response. The mageia-dev mailing list provided no useful
response in both September and February.
https://bugs.mageia.org/show_bug.cgi?id=15662 has generated no response as
well. Only place left that makes sense to try is kernel, maybe KMS fault
switching back from 1600x1200 to 1024x768?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] CAD often useless

[Felix Miata]

Lennart Poettering composed on 2015-04-16 12:32 (UTC+0200):

> Felix Miata wrote:

>> Needing again to CAD on yet another machine (kt88b this time, kt400 earlier),
>> again encountering / going into RO state, I noticed this time the message
>> "Ctrl-Alt-Del was pressed more than 7 times within 2s, rebooting
>> immediately". I remember having seen this on previous occasions to need CAD,
>> but it's still on the screen now, several minutes later, with the NUM key's
>> LED remaining responsive. IOW, it doesn't do either what it says, or what I
>> wanted. This is on F22 with PAE kernel 4.0.0-1 and PATA storage only except
>> for empty floppy drive.

> When you see this message, then systemd will not bother with shuttding
> down daemons cleanly anymore. However, it will still unmount all file
> systems and sync things do disk. It will also pass control back to the
> initrd,

So if initrd is deleted or rebuilt for the running kernel, shut down normally
is not possible?

> which might disassemble LVM if that is used.

NA here.

> If things hang in that logic then this is either an issue with
> LVM/initrd, or with your driver/hw when we try to sync the disks.

Definitely the disks in the two systems that triggered the thread...

> Given that your fs was remounted read-only (which the kernel does
> automatically if it notices something seriously wrong with the disk),
> my guess is that the disk syncing trips you up.

In the latter of the two, I found the cheapie PS has flimsy connectors after
subsequent POST couldn't find the disk. I pinched them all closed on and
reconnected the one for the HD, and its trouble stopped. In the former, there
was some problem with cabling as well, but I already forgot what. :-p
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel