Re: [systemd-devel] deny access to GPU devices

[Topi Miettinen]

On 11/11/16 20:09, Lennart Poettering wrote:
> I have no idea what "slurm" is, but do note that the "devices" cgroup
> controller has no future, it is unlikely to ever become available in
> cgroupsv2.

This is unwelcome news, I think it is a simple and well contained MAC
that has been available in systems without a full blown MAC like SELinux
and with systemd support it has been very easy to set up. What will
happen to DevicePolicy, DeviceAllow etc. directives? Or will systemd
stick to cgroupsv1 forever?

> Device access to local users is normally managed through ACLs on the
> device node, via udev/logind's "uaccess" logic. Using the "devices"
> cgroup controller for this appears pretty misguided...

ACLs only limit access via the path that they are controlling, device
cgroup controlled the whole system. And if you have a MAC system that
can do that, it could perform the same task as ACLs but in a much better
way.

With cgroup you could also deny access to nodes that need to be
available for interactive users (like TTYs, audio, input devices, GPUs,
USB devices), but which are not useful for system services. Perhaps some
sort of ACL could be constructed with the same effect.

> Also, were does 195 come from? is that a hardcoded major of the
> closed-source nvidia driver? Yuck, code really shouldn't hardcode
> major/minor numbers these days... And sec

The reason seems to be that kernel devs chose not to expose the required
API to non-GPL modules, probably to give pressure to switch to GPL. As
that has not happened, the situation is not optimal for end user point
of view, but it's certainly within the devs' and module authors' rights
to continue using incompatible licences.

NVIDIA tackles this by shipping a SUID root helper nvidia-modprobe,
which is of course even worse from security point of view but it works.
This also highlights why having the device cgroup is a good idea, for
example the helper could be fooled to create new device nodes without
the ACLs. In my setup I have disabled the helper and the device nodes
are created with tmpfiles, which means I'm able to remove CAP_MKNOD
capability and any device cgroup 'm' rights from Xorg service running as
non-root user.

-Topi

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

Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

[Lennart Poettering]

On Sun, 06.11.16 11:41, Reindl Harald (h.rei...@thelounge.net) wrote:

> > You mix two different things.
> > 
> > 1. The behavior that if filesystem from /etc/fstab fails to mount, boot
> > is stopped and administrator intervention is required existed long
> > before systemd.
> > 
> > 2. Password is requested not by systemd, but by command that it starts
> > to present shell. Default is sulogin. You are free to override it with
> > anything you want, including /bin/sh. Again, sulogin was often default
> > in this case before systemd as well
> 
> no he don't - fact is before systemd the amchine bootet as long as the disk
> containing the operating system was there with or without "nofail"
> 
> the current behavior is correct but "machine stops booting and require
> password" in fact is "new" on systemd driven machines

Some distros chose to ignore failure reported by "mount". systemd does
not. I think it was a bug in those systems to ignore it. But of
course, people are welcome to disagree, and downstream distros may
of course choose to patch systemd to ignore the exit code of mount if
they like. But quite frankly, I am pretty sure that'd be a *very*
poor choice...

Lennart

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

Re: [systemd-devel] systemd-nspawn containers

[Michał Zegan]

well you can read user_namespaces(7), the beginning of it at least. it
probably says something about keyrings. so either this info is
incorrect, or I for example understand it wrongly, or whatever.
Also, you know, when you say that currently containers have holes and so
are still not really secure I don't actually see any example of that
except this small number of things you just cannot do there at all (for
example use/access audit or use fuse/file capabilities), and those like
cgroups that are work in progress at this very moment. Well, file caps
are also work in progress at the moment I believe, I saw some patches
lately. I don't see such problems probably because I am not a security
expert and I am not working with any kind of servers/containers in
production, this technology is just extremely interesting for me.

W dniu 11.11.2016 o 19:41, Lennart Poettering pisze:
> On Fri, 11.11.16 19:36, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Why do you turn off keyrings? at least manpages say that userns
>> virtualizes keyrings or something similar...
> 
> That'd be a new feature then...
> 
> Lennart
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn containers

[Michał Zegan]

Why do you turn off keyrings? at least manpages say that userns
virtualizes keyrings or something similar...

W dniu 11.11.2016 o 19:24, Lennart Poettering pisze:
> On Fri, 11.11.16 19:21, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> audit/autofs are not properly virtualized, I know. But I thought
>> keyrings and cgroups are.
> 
> most container managers turn off keyrings entirely (as we do in nspawn
> actually).
> 
> delegating controllers in cgroupsv1 is unsafe, if you do it the
> container can make the system hang easily.
> 
> delegating controllers in cgroupvs2 is safe, but cgroupsv2 are
> incomplete as of now, the most relevant controller (cpu) is not
> available for it yet.
> 
> Lennart
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn containers

[Lennart Poettering]

On Fri, 11.11.16 19:36, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> Why do you turn off keyrings? at least manpages say that userns
> virtualizes keyrings or something similar...

That'd be a new feature then...

Lennart

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

Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process

[Tom H]

On Fri, Nov 11, 2016 at 4:13 PM, Michael Hirmke  wrote:
>
> Does anyone know, what "+::" in /etc/passwd means?

Users in the nis (by default) or nisplus db will be valid on that
system if you have "compat" on the "passwd" line of
"/etc/nsswitch.conf".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn containers

[Lennart Poettering]

On Fri, 11.11.16 19:21, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> audit/autofs are not properly virtualized, I know. But I thought
> keyrings and cgroups are.

most container managers turn off keyrings entirely (as we do in nspawn
actually).

delegating controllers in cgroupsv1 is unsafe, if you do it the
container can make the system hang easily.

delegating controllers in cgroupvs2 is safe, but cgroupsv2 are
incomplete as of now, the most relevant controller (cpu) is not
available for it yet.

Lennart

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

Re: [systemd-devel] systemd-nspawn containers

[Michał Zegan]

audit/autofs are not properly virtualized, I know. But I thought
keyrings and cgroups are.

W dniu 11.11.2016 o 18:28, Lennart Poettering pisze:
> On Fri, 11.11.16 16:41, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Thank you for your answers!
>>
>> What I meant by secure containers is mostly, containers that are or will
>> be secure enough to use them for things like virtual private server
>> hosting. Is nspawn intended to be usable for such things in the future,
>> or maybe it already is, or whatever?
> 
> I run my own server this way, already as an exercise of dogfooding.
> 
> So, yes, running a VPS like this certainly works, but do note that
> nspawn doesn't do orchestration or anything. It's good enough for me,
> but if you needy fancy orchestration tools then nspawn won't be
> sufficient.
> 
>> What kernel limitations do you mean when you say about security?
> 
> Well, a lot of subsystems cannot be locked down properly for use in
> containers yet. You can lock down a lot, in particular if you use
> userns, but there are still a lot of holes in there, and in particular
> userns itself has been a major source of CVEs alone in the most recent
> kernels.
> 
> Right now, "containers" in general are not about security. Some
> companies claim they were secure, but they really aren't. And that's
> not a bug in nspawn, or docker, or lxc for that matter, it's simply a
> limiation of the kernel.
> 
> Or to say this differently: we'll do in nspawn everything we can to
> lock things down properly, but there are limits based on what the
> kernel provides... As the kernel gets improved in this area, we'll
> update nspawn to make use of it. We are sitting in the same boat in
> this regard as others container managers, and they have the same
> limits more or less we have.
> 
>> For now I know that in full containers with userns file capabilities do
>> not work (I think), you have no virtualized /proc/meminfo and friends
>> (do cgroup namespaces give a chance to change that?), you cannot mknod
>> devices (no whitelist possible at this level), no fuse support, no
>> automatic uid shifting kernel level, no possibility to mount physical
>> filesystems in userns, and no possibility to have selinux/etc per
>> container. Do you mean such limitations or something else?
> 
> Well, devices are not virtualized at all (with the exception of
> network devices), that means no udev, not hotplug events and so
> on. Some container managers ignore this, and provide access to
> selected device nodes anyway, but we don't do something like that in
> nspawn, since it's pretty broken (as /sys wouldn't match what you see
> in /dev). In general, I think people should just accept that
> containers mean "you don't get physical device access". And if you
> want physical device access, then don't use containers...
> 
>> I am interested in this topic but it is quite hard for me to track
>> progress in that area (kernel side) even though I subscribe in some
>> kernel ml's and know at least about submitted patches, or some of
>> them. What else is missing that I didn't say about that would be
>> good to have?
> 
> Well, a lot of stuff is still not properly virtualized. To mind come
> audit, autofs, keyring, cgroups, …
> 
>> Also what about setting cgroup parameters per container? nspawn does not
>> allow doing that, and you probably do not intent it to be done by
>> overriding container's scope unit settings, for example?
> 
> You can actually do that just fine. Simply set it in the nspawn  service
> file. Or if you run nspawn from the cmdline with the "-p" switch. Or
> make your changes dynamically via "systemctl set-property". It's all
> supported and works well.
> 
> Lennart
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [libvirt] How to make udev not touch my device?

[Lennart Poettering]

On Mon, 07.11.16 09:17, Daniel P. Berrange (berra...@redhat.com) wrote:

> On Fri, Nov 04, 2016 at 08:47:34AM +0100, Michal Privoznik wrote:
> > Hey udev developers,
> > 
> > I'm a libvirt developer and I've been facing an interesting issue
> > recently. Libvirt is a library for managing virtual machines and as such
> > allows basically any device to be exposed to a virtual machine. For
> > instance, a virtual machine can use /dev/sdX as its own disk. Because of
> > security reasons we allow users to configure their VMs to run under
> > different UID/GID and also SELinux context. That means that whenever a
> > VM is being started up, libvirtd (our daemon we have) relabels all the
> > necessary paths that QEMU process (representing VM) can touch.
> > However, I'm facing an issue that I don't know how to fix. In some cases
> > QEMU can close & reopen a block device. However, closing a block device
> > triggers an event and hence if there is a rule that sets a security
> > label on a device the QEMU process is unable to reopen the device again.
> > 
> > My question is, whet we can do to prevent udev from mangling with our
> > security labels that we've set on the devices?
> > 
> > One of the ideas our lead developer had was for libvirt to set some kind
> > of udev label on devices managed by libvirt (when setting up security
> > labels) and then whenever udev sees such labelled device it won't touch
> > it at all (this could be achieved by a rule perhaps?). Later, when
> > domain is shutting down libvirt removes that label. But I don't think
> > setting an arbitrary label on devices is supported, is it?
> 
> Having thought about this over the weekend, I'm strongly inclined to
> just take udev out of the equation by starting a new mount namespace
> for each QEMU we launch and setting up a custom /dev containing just
> the devices we need. This will be both a security improvement and
> avoid the udev races, with no complex code required in libvirt and
> will work for libvirt all the way back to RHEL6

I think this would be a pretty nice solution, indeed!

Lennart

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

Re: [systemd-devel] [libvirt] How to make udev not touch my device?

[Lennart Poettering]

On Fri, 11.11.16 14:15, Michal Sekletar (msekl...@redhat.com) wrote:

> On Mon, Nov 7, 2016 at 1:20 PM, Daniel P. Berrange  
> wrote:
> 
> > So if libvirt creates a private mount namespace for each QEMU and mounts
> > a custom /dev there, this is invisible to udev, and thus udev won't/can't
> > mess with permissions we set in our private /dev.
> >
> > For hotplug, the libvirt QEMU would do the same as the libvirt LXC driver
> > currently does. It would fork and setns() into the QEMU mount namespace
> > and run mknod()+chmod() there, before doing the rest of its normal hotplug
> > logic. See lxcDomainAttachDeviceMknodHelper() for what LXC does.
> 
> We try to migrate people away from using mknod and messing with /dev/
> from user-space. For example, we had to deal with non-trivial problems
> wrt. mknod and Veritas storage stack in the past (most of these issues
> remain unsolved to date). I don't like to hear that you plan to get
> into /dev management business in libvirt too. I am judging based on
> past experiences, nevertheless, I don't like this plan.

Well, I'd say: if people create their own /dev, they are welcome to do
in it whatever they want. They should just stay away from the host's
/dev however, and not interfere with udev's own managing of that.

Lennart

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

Re: [systemd-devel] systemd-nspawn leaves leftovers in /tmp

[Lennart Poettering]

On Fri, 04.11.16 15:54, Bill Lipa (d...@masterleep.com) wrote:

> This might be due to trying to use systemd-nspawn -x with a raw image
> inside the btrfs /var/lib/machines volume.  It doesn't work in the
> sense that the container isn't ephemeral, but there's no error message
> either, and this leftover gets created.
> 
> If I jump through elaborate hoops to create the container as a btrfs
> subvolume instead of using the pull-raw one liner, the -x flag works
> as expected and there is no leftover in /tmp.

"-x" should work with raw images too. If it doesn't, that'd be a
bug. Please file a github issue about this bug!

Thanks,

Lennart

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

Re: [systemd-devel] systemd-nspawn containers

[Lennart Poettering]

On Fri, 11.11.16 16:41, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> Thank you for your answers!
> 
> What I meant by secure containers is mostly, containers that are or will
> be secure enough to use them for things like virtual private server
> hosting. Is nspawn intended to be usable for such things in the future,
> or maybe it already is, or whatever?

I run my own server this way, already as an exercise of dogfooding.

So, yes, running a VPS like this certainly works, but do note that
nspawn doesn't do orchestration or anything. It's good enough for me,
but if you needy fancy orchestration tools then nspawn won't be
sufficient.

> What kernel limitations do you mean when you say about security?

Well, a lot of subsystems cannot be locked down properly for use in
containers yet. You can lock down a lot, in particular if you use
userns, but there are still a lot of holes in there, and in particular
userns itself has been a major source of CVEs alone in the most recent
kernels.

Right now, "containers" in general are not about security. Some
companies claim they were secure, but they really aren't. And that's
not a bug in nspawn, or docker, or lxc for that matter, it's simply a
limiation of the kernel.

Or to say this differently: we'll do in nspawn everything we can to
lock things down properly, but there are limits based on what the
kernel provides... As the kernel gets improved in this area, we'll
update nspawn to make use of it. We are sitting in the same boat in
this regard as others container managers, and they have the same
limits more or less we have.

> For now I know that in full containers with userns file capabilities do
> not work (I think), you have no virtualized /proc/meminfo and friends
> (do cgroup namespaces give a chance to change that?), you cannot mknod
> devices (no whitelist possible at this level), no fuse support, no
> automatic uid shifting kernel level, no possibility to mount physical
> filesystems in userns, and no possibility to have selinux/etc per
> container. Do you mean such limitations or something else?

Well, devices are not virtualized at all (with the exception of
network devices), that means no udev, not hotplug events and so
on. Some container managers ignore this, and provide access to
selected device nodes anyway, but we don't do something like that in
nspawn, since it's pretty broken (as /sys wouldn't match what you see
in /dev). In general, I think people should just accept that
containers mean "you don't get physical device access". And if you
want physical device access, then don't use containers...

> I am interested in this topic but it is quite hard for me to track
> progress in that area (kernel side) even though I subscribe in some
> kernel ml's and know at least about submitted patches, or some of
> them. What else is missing that I didn't say about that would be
> good to have?

Well, a lot of stuff is still not properly virtualized. To mind come
audit, autofs, keyring, cgroups, …

> Also what about setting cgroup parameters per container? nspawn does not
> allow doing that, and you probably do not intent it to be done by
> overriding container's scope unit settings, for example?

You can actually do that just fine. Simply set it in the nspawn  service
file. Or if you run nspawn from the cmdline with the "-p" switch. Or
make your changes dynamically via "systemctl set-property". It's all
supported and works well.

Lennart

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

Re: [systemd-devel] [libvirt] How to make udev not touch my device?

[Daniel P. Berrange]

On Fri, Nov 11, 2016 at 05:01:40PM +0100, Michal Sekletar wrote:
> On Fri, Nov 11, 2016 at 2:20 PM, Daniel P. Berrange  
> wrote:
> 
> > What kind of issues ?
> 
> General problem with manually created device nodes is that udev and
> systemd do not know about them. Device units do not exist for these
> device nodes. Hence these device units can not be a dependency of some
> other unit. Typical example is manually created device node referenced
> from /etc/fstab. Then corresponding mount unit is bound to a device
> that never shows up and hence it always fails to mount even tough
> device node is there.

Ok, that sounds irrelevant to libvirt's usage wrt QEMU, so I don't
see any problem for us here.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [libvirt] How to make udev not touch my device?

[Michal Sekletar]

On Fri, Nov 11, 2016 at 2:20 PM, Daniel P. Berrange  wrote:

> What kind of issues ?

General problem with manually created device nodes is that udev and
systemd do not know about them. Device units do not exist for these
device nodes. Hence these device units can not be a dependency of some
other unit. Typical example is manually created device node referenced
from /etc/fstab. Then corresponding mount unit is bound to a device
that never shows up and hence it always fails to mount even tough
device node is there.

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

Re: [systemd-devel] systemd-nspawn containers

[Michał Zegan]

Thank you for your answers!

What I meant by secure containers is mostly, containers that are or will
be secure enough to use them for things like virtual private server
hosting. Is nspawn intended to be usable for such things in the future,
or maybe it already is, or whatever?
What kernel limitations do you mean when you say about security?
For now I know that in full containers with userns file capabilities do
not work (I think), you have no virtualized /proc/meminfo and friends
(do cgroup namespaces give a chance to change that?), you cannot mknod
devices (no whitelist possible at this level), no fuse support, no
automatic uid shifting kernel level, no possibility to mount physical
filesystems in userns, and no possibility to have selinux/etc per
container. Do you mean such limitations or something else? I am
interested in this topic but it is quite hard for me to track progress
in that area (kernel side) even though I subscribe in some kernel ml's
and know at least about submitted patches, or some of them. What else is
missing that I didn't say about that would be good to have?

Also what about setting cgroup parameters per container? nspawn does not
allow doing that, and you probably do not intent it to be done by
overriding container's scope unit settings, for example?

W dniu 11.11.2016 o 13:52, Lennart Poettering pisze:
> On Wed, 09.11.16 18:24, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Hello.
>>
>> Does systemd-nspawn intent to be a full secure container technology? or
>> it maybe already is? what is missing?
> 
> I am not sure what "full secure container technology" realls is
> supposed to mean.
> 
> nspawn right now is great for two things:
> 
> a) full OS containers (think VMs, except based on container
>technology. This means that inside the container you have a proper
>PID 1 running, and a network configuration daemon and most other
>things that would run on a normal, physical system, except one
>thing: no device manager, as the kernel does not virtualize
>devices)
> 
> b) as a building block for whatever you want it to be. It's a pretty
>generic tool, you can use as base for anything you like. The "rkt"
>container manager makes use of this facet.
> 
> There are a number of things nspawn is better at than other container
> managers, for example in conjunction with networkd networking happens
> pretty much entirely automatically out of the box. It also ships
> userns support that is relatively usable without much manual
> intervention. OTOH it clearly doesn't do a lot of stuff that other
> container managers do and we have no intention to ever do: do IP level
> configuration in the manager itself, support for ZFS and other exotic
> (possibly out-of-tree) storage technology, and so on.
> 
> So it really depends what you mean by "full secure container
> technology". We do a lot, we will add more, but there are also things
> I don't see on our list at all.
> 
> (And "secure" is a difficult thing anyway, currently security of
> containers on Linux is pretty limited in general, due to kernel
> limitations.)
> 
> Lennart
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] 250 USD bounty for adding NUMA support to systemd

[Lennart Poettering]

Heya!

For those hackers who need a financial incentive to hack on systemd:
somebody posted a 250 USD bounty for an RFE issue on github:

https://github.com/systemd/systemd/issues/3097

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

Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process

[Michael Hirmke]

Hi Markus,

>On Friday 11 November 2016 15:13:00 Michael Hirmke wrote:

>> Does anyone know, what "+::" in /etc/passwd means?

>This line is for the NIS client.

thx for the explanation.

>regards
>Markur Köberl

Bye.

Bye.
Michael.
-- 
Michael Hirmke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process

[Michael Hirmke]

Hi Simon,

>On Fri, 11 Nov 2016 at 15:13:00 +0100, Michael Hirmke wrote:
>> Does anyone know, what "+::" in /etc/passwd means?

>It's to do with the NSS "compat" plugin, which glues together
>NIS and a traditional password file.
>Look for "Compatibility mode (compat)" in
>http://man7.org/linux/man-pages/man5/nsswitch.conf.5.html

thx.
There seems to be a bug somewhere, I suppose.
Either entries behind that line shouldn't be ignored or all entries
have to be written before that line.

Ok, but that has nothing to do with systemd ;)

>S

Bye.
Michael.
-- 
Michael Hirmke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to run a script which takes about 30 seconds before shutdown

[Lennart Poettering]

On Fri, 11.11.16 22:31, zerons (sironhide0n...@gmail.com) wrote:

> >> Hi everyone.
> >>
> >> Everyday, I need to do something like `git pull` after system
> >> bootup and `git push` before shutdown. I am using Ubuntu 16.04.
> >> I have tried to put some script into /etc/rc0.d/, /etc/rc6.d/,
> >> each time the script runs, the network has been stopped, so I 
> >> turn to systemd.
> >>
> >>
> >> === Here is a test .service file.
> >> [Unit]
> >> Description=test systemd
> >> Conflicts=reboot.target
> >> After=network-online.target
> >> Wants=network-online.target
> > 
> > If you only care about shutdown, then After=network.target shouls
> > suffice, as long as your network management service properly orders
> > itself against that. See systemd.special(7) for details on this.
> > 
> > Note that systemd only provides a number of hooks we document
> > semantics for, but it's up to downstream packages to actually honour
> > these correctly.
> > 
> > Lennart
> > 
> 
> Thanks, I have tried this. When this script runs, `ifconfig`-> `ping`
> -> `ifconfig`, when `ping` runs, the network is unreachable, packet 87%
> loss(only the first one received), then the net interface has no
> "inet addr". I couldn't figure this out:(

That suggests your network management service of choice is not
ordering itself properly against network.target. Please file a bug
against it.

Lennart

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

Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process

[Markus Koeberl]

On Friday 11 November 2016 15:13:00 Michael Hirmke wrote:

> Does anyone know, what "+::" in /etc/passwd means?

This line is for the NIS client.


regards
Markur Köberl
-- 
Markus Koeberl
Graz University of Technology
Signal Processing and Speech Communication Laboratory
E-mail: markus.koeb...@tugraz.at
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process

[Simon McVittie]

On Fri, 11 Nov 2016 at 15:13:00 +0100, Michael Hirmke wrote:
> Does anyone know, what "+::" in /etc/passwd means?

It's to do with the NSS "compat" plugin, which glues together
NIS and a traditional password file.
Look for "Compatibility mode (compat)" in
http://man7.org/linux/man-pages/man5/nsswitch.conf.5.html

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

Re: [systemd-devel] how to run a script which takes about 30 seconds before shutdown

[zerons]

On 11/11/2016 08:44 PM, Lennart Poettering wrote:
> On Wed, 09.11.16 21:11, zerons (sironhide0n...@gmail.com) wrote:
> 
>> Hi everyone.
>>
>> Everyday, I need to do something like `git pull` after system
>> bootup and `git push` before shutdown. I am using Ubuntu 16.04.
>> I have tried to put some script into /etc/rc0.d/, /etc/rc6.d/,
>> each time the script runs, the network has been stopped, so I 
>> turn to systemd.
>>
>>
>> === Here is a test .service file.
>> [Unit]
>> Description=test systemd
>> Conflicts=reboot.target
>> After=network-online.target
>> Wants=network-online.target
> 
> If you only care about shutdown, then After=network.target shouls
> suffice, as long as your network management service properly orders
> itself against that. See systemd.special(7) for details on this.
> 
> Note that systemd only provides a number of hooks we document
> semantics for, but it's up to downstream packages to actually honour
> these correctly.
> 
> Lennart
> 

Thanks, I have tried this. When this script runs, `ifconfig`-> `ping`
-> `ifconfig`, when `ping` runs, the network is unreachable, packet 87%
loss(only the first one received), then the net interface has no
"inet addr". I couldn't figure this out:(
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process

[Michael Hirmke]

Hi Lennart,

>On Fri, 11.11.16 14:41, Michael Hirmke (m...@mike.franken.de) wrote:

>> Hi *,
>>
>> can anyone help me with this error message:
>>
>> systemd-timesyncd[857]: Cannot resolve user name systemd-timesync: No
>> such process
>>
>> This happens with systemd-228-13.1.x86_64 on openSuSE Leap 42.2 RC2.
>>
>> The user account systemd-timesync exists in /etc/passwd.

>What does "getent passwd systemd-timesync" and "getent group
>systemd-timesync" report?

getent passwd systemd-timesync
-> returns nothing

getent group systemd-timesync
-> returns:
systemd-timesync:x:463:


I found an entry "+::" in my passwd - no idea, what that means. I've
never seen that. All entries after that one are reported as non existent
by getent. I moved this line to the end of the file, and getent reports
the entries missing before.

Thx for that hint.

Does anyone know, what "+::" in /etc/passwd means?

>Lennart

Bye.
Michael.
-- 
Michael Hirmke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] machinectl shell vs systemd-run

[Lennart Poettering]

On Sat, 05.11.16 21:06, Wilhelm Schuster (w...@wilhelm.re) wrote:

> Hi,
> 
> I’m trying to run a command inside a container (spawned via
> nspawn). `machinectl shell` and `systemd-run` seem like two ways
> that accomplish that in systemd. Machinectl’s man page [0] states
> the following:
> 
> Note that systemd-run(1) may be used in place of the shell command,
> […]. However, it is frequently more privileged than the shell
> command.
> 
> I’m interested in the last part here. Specifically when does
> `systemd-run` have more privileges than `machinectl shell` and what
> are those additional privileges?

So, the difference boils down to the PolicyKit check that is
done. "systemd-run" generically creates a transient unit in
systemd. It's protected by the "org.freedesktop.systemd1.manage-units"
action, and if you grant that privilege to a user, then he or she can
create arbitrary transient units and set any property on that they
like to any value they like.

OTOH "machinectl shell" is protected by the PK actions
"org.freedesktop.machine1.shell" and
"org.freedesktop.machine1.host-shell" (the latter is used when using
it on the host itself), and you can only really execute a command,
nothing else. You cannot change arbitrary properties beyond the
command line.

The gist of this is really: if you grant a user
"org.freedesktop.machine1.shell" then she or he can connect to any
local container and get a shell, there, but they cannot fuck up the host.

Hope this makes sense?

Lennart

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

Re: [systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process

[Lennart Poettering]

On Fri, 11.11.16 14:41, Michael Hirmke (m...@mike.franken.de) wrote:

> Hi *,
> 
> can anyone help me with this error message:
> 
> systemd-timesyncd[857]: Cannot resolve user name systemd-timesync: No
> such process
> 
> This happens with systemd-228-13.1.x86_64 on openSuSE Leap 42.2 RC2.
>
> The user account systemd-timesync exists in /etc/passwd.

What does "getent passwd systemd-timesync" and "getent group
systemd-timesync" report?

Lennart

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

[systemd-devel] systemd-timesyncd: Cannot resolve user name systemd-timesync: No such process

[Michael Hirmke]

Hi *,

can anyone help me with this error message:

systemd-timesyncd[857]: Cannot resolve user name systemd-timesync: No
such process

This happens with systemd-228-13.1.x86_64 on openSuSE Leap 42.2 RC2.

The user account systemd-timesync exists in /etc/passwd.

timedatectl output:

  Local time: Fr 2016-11-11 14:40:58 CET
  Universal time: Fr 2016-11-11 13:40:58 UTC
RTC time: Fr 2016-11-11 13:40:58
   Time zone: Europe/Berlin (CET, +0100)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no


Thx and bye.
Michael.
-- 
Michael Hirmke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [libvirt] How to make udev not touch my device?

[Daniel P. Berrange]

On Fri, Nov 11, 2016 at 02:15:38PM +0100, Michal Sekletar wrote:
> On Mon, Nov 7, 2016 at 1:20 PM, Daniel P. Berrange  
> wrote:
> 
> > So if libvirt creates a private mount namespace for each QEMU and mounts
> > a custom /dev there, this is invisible to udev, and thus udev won't/can't
> > mess with permissions we set in our private /dev.
> >
> > For hotplug, the libvirt QEMU would do the same as the libvirt LXC driver
> > currently does. It would fork and setns() into the QEMU mount namespace
> > and run mknod()+chmod() there, before doing the rest of its normal hotplug
> > logic. See lxcDomainAttachDeviceMknodHelper() for what LXC does.
> 
> We try to migrate people away from using mknod and messing with /dev/
> from user-space. For example, we had to deal with non-trivial problems
> wrt. mknod and Veritas storage stack in the past (most of these issues

What kind of issues ? 

> remain unsolved to date). I don't like to hear that you plan to get
> into /dev management business in libvirt too. I am judging based on
> past experiences, nevertheless, I don't like this plan.

Libvirt is already doing this for its LXC driver, populating a private
/dev with only the devices permitted for the container in question.

> Also, managing separate mount namespace for each qemu process and
> forking helper that joins the namespace to do some work seems quite
> complex too.

Again, libvirt is already doing this for LXC so its not any great
burden.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [libvirt] How to make udev not touch my device?

[Michal Sekletar]

On Mon, Nov 7, 2016 at 1:20 PM, Daniel P. Berrange  wrote:

> So if libvirt creates a private mount namespace for each QEMU and mounts
> a custom /dev there, this is invisible to udev, and thus udev won't/can't
> mess with permissions we set in our private /dev.
>
> For hotplug, the libvirt QEMU would do the same as the libvirt LXC driver
> currently does. It would fork and setns() into the QEMU mount namespace
> and run mknod()+chmod() there, before doing the rest of its normal hotplug
> logic. See lxcDomainAttachDeviceMknodHelper() for what LXC does.

We try to migrate people away from using mknod and messing with /dev/
from user-space. For example, we had to deal with non-trivial problems
wrt. mknod and Veritas storage stack in the past (most of these issues
remain unsolved to date). I don't like to hear that you plan to get
into /dev management business in libvirt too. I am judging based on
past experiences, nevertheless, I don't like this plan.

Also, managing separate mount namespace for each qemu process and
forking helper that joins the namespace to do some work seems quite
complex too.

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

Re: [systemd-devel] systemd-nspawn containers

[Lennart Poettering]

On Wed, 09.11.16 18:24, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> Hello.
> 
> Does systemd-nspawn intent to be a full secure container technology? or
> it maybe already is? what is missing?

I am not sure what "full secure container technology" realls is
supposed to mean.

nspawn right now is great for two things:

a) full OS containers (think VMs, except based on container
   technology. This means that inside the container you have a proper
   PID 1 running, and a network configuration daemon and most other
   things that would run on a normal, physical system, except one
   thing: no device manager, as the kernel does not virtualize
   devices)

b) as a building block for whatever you want it to be. It's a pretty
   generic tool, you can use as base for anything you like. The "rkt"
   container manager makes use of this facet.

There are a number of things nspawn is better at than other container
managers, for example in conjunction with networkd networking happens
pretty much entirely automatically out of the box. It also ships
userns support that is relatively usable without much manual
intervention. OTOH it clearly doesn't do a lot of stuff that other
container managers do and we have no intention to ever do: do IP level
configuration in the manager itself, support for ZFS and other exotic
(possibly out-of-tree) storage technology, and so on.

So it really depends what you mean by "full secure container
technology". We do a lot, we will add more, but there are also things
I don't see on our list at all.

(And "secure" is a difficult thing anyway, currently security of
containers on Linux is pretty limited in general, due to kernel
limitations.)

Lennart

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

Re: [systemd-devel] how to run a script which takes about 30 seconds before shutdown

[Lennart Poettering]

On Wed, 09.11.16 21:11, zerons (sironhide0n...@gmail.com) wrote:

> Hi everyone.
> 
> Everyday, I need to do something like `git pull` after system
> bootup and `git push` before shutdown. I am using Ubuntu 16.04.
> I have tried to put some script into /etc/rc0.d/, /etc/rc6.d/,
> each time the script runs, the network has been stopped, so I 
> turn to systemd.
> 
> 
> === Here is a test .service file.
> [Unit]
> Description=test systemd
> Conflicts=reboot.target
> After=network-online.target
> Wants=network-online.target

If you only care about shutdown, then After=network.target shouls
suffice, as long as your network management service properly orders
itself against that. See systemd.special(7) for details on this.

Note that systemd only provides a number of hooks we document
semantics for, but it's up to downstream packages to actually honour
these correctly.

Lennart

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