sched_setattr() still can cause EPERM through natural causes
Recently !1356 (merged) was merged that fixed Fedora selinux issues, by checking first the syscall is allowed.
However this didn't fully fix the case of tracker-extract (tracker#180 (closed)). Unlike it was first thought, this is not an issue introduced by seccomp, but caused by:
nice(19) calls result on EPERM coming from:
sched_setattr() man page seems a bit vague on what EPERM means, giving it at least 2 meanings:
EPERM The caller does not have appropriate privileges. EPERM The CPU affinity mask of the thread specified by pid does not include all CPUs in the system (see sched_setaffinity(2)).
But all in all, it seems possible to end up with it through other legit syscalls in the same process, IMHO
g_error() seems disproportionate.