Setpriority bad system call

I have an application (Game) I’m snapping which gets killed with “Bad system call”. In dmesg I see:

“syscall=141”.

I did a search onlline and found an irc conversation about the setpriority call from about a year ago. I spoke to @zyga-snapd at the sprint who suggested I mention this to @tyhicks as work has been done to allow us to ignore this syscall and allow the app to proceed rather than kill it (as we currently do). So I’m bringing it up here so the conversation is easier to find than an IRC conversation from the past, and get comment from @tyhickson when we can expect this to work. @zyga-snapd suggested this might be is some months away?

have a look at Auto-connecting the process-control interface for the 0ad snap

1 Like

We can use the process control interface to do this but I’d rather not apply it to all the games in the store. Perhaps in absence of seccomp complain mode and using EPERM rather than killing the process, we could create a new interface that lets applications rise their priority by some degree without gaining all of the permissions otherwise granted by process-control

There are a couple of things here. 1) while we could create an interface that allows adjusting the priority only, we can’t mediate that per-process so the snap could raise the priority everywhere which to me is not an interface we want to grant to games any more than the process-control interface and 2) the game is coded incorrectly-- we allow changing priority to 0-19 which is what non-root is allowed to do, but the game is running as non-root and getting blocked because it is trying to go to negative values which aren’t allowed by the kernel anyway.

IMO, the answer is seccomp EPERM-- this will make seccomp sandbox behave to the application the same way as without it.

1 Like

Sorry to resurrect a long aged thread. The current state is the same, right? I (and others) currently can’t upload any games to the store built using the Construct3 tool (based on nwjs)?

@tyhicks has been getting the pieces in place for snappy to deny and log but not kill the process. AIUI, all of that work is submitted upstream, but I’m not sure of the other details. @tyhicks, can you comment on this?

This bug comment has the latest status. I’m currently waiting on the libseccomp PR to be reviewed by upstream.

Just so I have this clear in my head. I notice that bug 1567597 is ‘fix released’ on the kernel part. Still more work to do in libseccomp and snapd? Will this fix (when done) mean I can install the above snap on Ubuntu 17.10 and it work, what about 16.04 and other non-Ubuntu systems? Does this fix depend on the kernel changes, is I guess what I want to know?

Apologies for not fully understanding these complex moving parts.

Hey @popey

We don’t have the corresponding snapd part of the fix or the necessary library changes yet. Depending on how things are implemented we should be able to gracefully detect this feature and do the best thing we can.

@zyga-snapd the library changes are now available. A minimal version of the libseccomp changes has landed in artful and my libseccomp-golang changes have received a positive initial review. While the libseccomp and libseccomp-golang PRs still need a little more polish to be merged upstream, we can leverage these minimal changes just to allow SECCOMP_RET_LOG through for developer mode.

There’s no dependency on libseccomp for changing to SECCOMP_RET_ERRNO by default in strict mode and all the kernel changes are available in Artful to do this today.

1 Like

This sounds very promising. What are the next steps? Do you plan to make changes to snapd? Shall we sync about the plan this week?

Did this move forward since last month?

It did move but due to sprints it’s not merged or available in edge yet.

FYI, this has moved forward. Please see https://github.com/snapcore/snapd/pull/3998 which will hopefully be merged this week.

1 Like