[PATCH] tst-personality: Check for ENOSYS

[Xi Ruoyao]

On Thu, 2023-07-27 at 10:40 -0300, Adhemerval Zanella Netto wrote:
> 
> 
> On 27/07/23 10:25, Xi Ruoyao via Libc-alpha wrote:
> > On Thu, 2023-07-27 at 09:02 -0400, Joe Simmons-Talbott wrote:
> > > On Thu, Jul 27, 2023 at 10:20:37AM +0800, Xi Ruoyao wrote:
> > > > On Wed, 2023-07-26 at 22:16 -0400, Carlos O'Donell via Libc-alpha wrote:
> > > > > On 7/25/23 13:57, Joe Simmons-Talbott via Libc-alpha wrote:
> > > > > > Return UNSUPPORTED if personality fails with ENOSYS.
> > > > > 
> > > > > Where did you see this?
> > > > 
> > > > Some "container environment" I guess.  Note that personality is added in
> > > > Linux 1.1.20 so there is no way a Linux system does not have this
> > > > syscall today.
> > > > 
> > > > To me we really should not try to support all these container
> > > > environments with too-clever seccomp filters.
> > > 
> > > Yes it is a podman container on x86_64-linux-gnu.  This is my main
> > > developement envrionment where I'm seeing a handful of testcases that
> > > fail.
> > 
> > Seccomp filter can block arbitrary syscall and we have no way to support
> > all the seccomp filters in the wild.
> > 
> > More generally, if you've specified --with-kernel=x.y but the a syscall
> > available in Linux x.y returns ENOSYS, the situation is considered
> > "broken kernel ABI" and not a Glibc bug.  So there is nothing to be
> > fixed here.
> > 
> > Try to disable seccomp filter (I'm not sure if podman has an option to
> > control it, but if not I'd be very surprised).
> > 
> 
> 
> We have this policy on glibc code itself, so we can use any fallback safely
> without the need to evaluate whether EPERM does make sense or if it should
> be reported to caller.  This symbol is not used internally, so filtering
> is possible without much trouble.
> 
> For tests I think it is feasible to work around Linux security filters and
> we already have a bug report to track it [1]. As I said in last patch review
> meeting, this kind of environment should be ok for CI/patchwork but we still
> need to occasionally and specially on release workflow to run make check on
> environment with maximum coverage to avoid having too much UNSUPPORTED
> tests.
> 
> Also, the personality syscall is a trick one because Linux kABI always
> succeed and thus there is no easy way to correct filter it (filtering is 
> always broken on 32 bits for instance [2]).

Frankly I've never considered seccomp a good containment mechanism... 
To me the if the other facilities (namespacing, cgroup, and the
traditional UNIX permissions) are used correctly there is no need to
seccomp things at all.  And these facilities are much less "arbitrary"
than seccomp.

As an ICPC coach: the online judge system for our online programming
competitions had used to rely on seccomp, but it just started to reject
valid programs for **each** glibc or libstdc++ update and we needed to
spend a lot of time testing and adjusting the seccomp whitelist.  Now
we've kicked seccomp out of the judge system.

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30603
> [2] https://patchwork.sourceware.org/project/glibc/patch/20230606164830.126052-1-adhemerval.zanella@linaro.org/

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University