Re: [systemd-devel] How to disable seccomp in systemd-nspawn?

[Mohan R]

Hi

On Fri, Jun 26, 2020 at 9:23 PM Lennart Poettering
 wrote:
> You might need a newer libseccomp so that the syscall is actually
> known by it. openat2 is a very recent syscall addition, and you need
> to update libseccomp in lockstep if you want it to grok it.

Thanks for the details, I'll look into it. Anyway, is there any
specific reason for not providing an option to disable seccomp (or
make seccomp opt-in instead of default)?

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

Re: [systemd-devel] How to disable seccomp in systemd-nspawn?

[Mohan R]

Hi

On Thu, Jun 25, 2020 at 2:17 PM Lennart Poettering
 wrote:
> You can't disable seccomp right now.

Any future plan to include a flag or some other way?

> We implement a system call allow list, i.e. everything that isn't
> explicitly allowed is denied. You can use --system-call-filter=openat2
> to allow a specific syscall on top of our defaults, i.e. extend the
> allow list, or remove entries from it.

This '--system-call-filter' isn't working,
https://gist.github.com/mohan43u/6ed44eff564f10cc04c709772b02c323

Is this a bug in systemd-nspawn?

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

[systemd-devel] How to disable seccomp in systemd-nspawn?

[Mohan R]

Hi,

How to disable seccomp in systemd-nspawn? I'm facing issue while
running fuse-overlayfs and I reported it

https://github.com/containers/fuse-overlayfs/issues/220#issuecomment-648865831

Developer asked me to check if the container is seccomp filtered, as
suspected systemd-nspawn put the container inside seccomp faltered
(Seccomp: 2). But I'm not able to get the list of filtered syscalls or
I'm not able to find out why 'openat2()' is returning EPERM inside the
systemd-nspawn container.

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

[systemd-devel] question regarding DBUS_SESSION_BUS_ADDRESS in multiseat environment

[Mohan R]

Hi,

I'm working on a display-manager for a multiseat environment. Here is how
we use logind

1. create new seat through udev
2. we set the XDG_SEAT in pamenv before calling pam_open_session()
3. we take XDG_SESSION_ID, XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS
from pam_systemd

Let say if a user already have a session(session0) in a seat (customseat0)
and he want to start another session in another seat (customseat1). Our
display manager would get the same DBUS_SESSION_BUS_ADDRESS from
pam_systemd for session1.

As we cannot use the same address for two sessions, we have to start
dbus-session manually. Using the address provided by dbus-session as
DBUS_SESSION_BUS_ADDRESS, we then proceed with starting gnome-keyring and
gnome-session.

Problem is, processes forked by 'systemd --user' will have
DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" but processes
forked by gnome-session will have
DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_PROVIDED_ADDRESS.

Is there any way to make pam_systemd provides uniq DBUS_SESSION_BUS_ADDRESS
for every session (may be unix:path=$XDG_RUNTIME_DIR/$XDG_SESSION_ID/bus)?
or is there any way to ask 'systemd --user' to provide different
DBUS_SESSION_BUS_ADDRESS to the childs?

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