Linux-man Archive on lore.kernel.org
 help / color / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: libc-alpha@sourceware.org, Florian Weimer <fweimer@redhat.com>,
	Szabolcs Nagy <Szabolcs.Nagy@arm.com>
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
	nd <nd@arm.com>, linux-man <linux-man@vger.kernel.org>
Subject: Re: glibc in master is incompatible with systemd-nspawn
Date: Fri, 08 Nov 2019 17:23:37 +0100
Message-ID: <52705C67-9908-4074-A5B2-4389FBDBA461@ubuntu.com> (raw)
In-Reply-To: <874kze1gt8.fsf@oldenburg2.str.redhat.com>

On November 8, 2019 5:19:47 PM GMT+01:00, Florian Weimer <fweimer@redhat.com> wrote:
>* Szabolcs Nagy:
>
>> it's of course broken whenever the application is
>> run on a newer kernel+libc than what was used for
>> creating the filter, may be the seccomp manual should
>> warn against the use of EPERM (there is already a
>> caveats section)?
>
>On this topic (ENOSYS vs PERM), I wrote earlier today:
>
>| They serve different purposes. EPERM is appropriate if you want
>things
>| to fail (so that applications break), ENOSYS is appropriate if you
>| want to trigger fallback (like utimensat_time64 → utime) or just
>| disable the feature (because the application assumes the kernel is
>too
>| old to support it). For a generic container runtime, there either
>have
>| to be no filters by default (my preference), or filters for unknown
>| system calls need to return ENOSYS. Everything else will break too
>| many applications.
>|
>| If you have specific knowledge of the system call, you can return
>| EPERM instead in a few cases (e.g. for clock_settime). But that's not
>| really possible for an unknown system call.
>
><https://bugzilla.redhat.com/show_bug.cgi?id=1769299>
>
>I don't know how controversial this position is.  People seem rather
>opinionated about EPERM.
>
>Thanks,
>Florian

Fwiw, with LXC and LXD we use ENOSYS.
I chatted with Lennart about this a few minutes ago.

      reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87k18a62xe.fsf@oldenburg2.str.redhat.com>
     [not found] ` <20191108141149.GB20533@altlinux.org>
     [not found]   ` <87v9ru1l6d.fsf@oldenburg2.str.redhat.com>
     [not found]     ` <c4001320-2d3f-9523-c93f-60f799545654@linaro.org>
2019-11-08 16:01       ` Szabolcs Nagy
2019-11-08 16:19         ` Florian Weimer
2019-11-08 16:23           ` Christian Brauner [this message]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52705C67-9908-4074-A5B2-4389FBDBA461@ubuntu.com \
    --to=christian.brauner@ubuntu.com \
    --cc=Szabolcs.Nagy@arm.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git