Comment 13 for bug 1897369

This message doesn't seem to affect anything, from what I can tell. Here's a technical analysis.

The system call, sched_setattr, is being made in glib's g_system_thread_get_scheduler_settings. It gets the current scheduling settings, and then tests to make sure it can set them on the same thread. This call is performed when the thread pool is being created, so that the initial scheduler settings can be recorded and applied to future threads. (If that's not possible, then glib has a different mechanism that it will use instead.)

In the Linux kernel, __sched_setscheduler (which does the work for sched_setattr) tests to see if the user is trying to do anything that requires the SYS_NICE capability. There are several tests it runs, all wrapped together:

/* Simplified version of the relevant kernel code */
if (!capable(CAP_SYS_NICE)) {
  if (new_nice < old_nice)
    return -EPERM;
  if (is_rt_policy(new_policy)) {
    if (new_policy != old_policy)
      return -EPERM;
    if (new_priority > old_priority && new_priority > rlim_rtprio)
      return -EPERM;
  }
  if (is_dl_policy(new_policy))
    return -EPERM;
  /* and so on */
}

All these are guarded by one check to see if the process is allowed to make changes that require CAP_SYS_NICE. This capability check is performed regardless of whether the app actually is trying to do something that requires CAP_SYS_NICE. (In this case, it's not trying to, but the check is made regardless.)

Ok, now we've outlined the components, so I'll paint the bigger picture. glib is testing to see if it can save and restore the scheduling parameters, albeit with no changes. The kernel checks to see if the process has the SYS_NICE capability. apparmor sees that the program doesn't have that capability, denies it, and logs an audit message. But the kernel continues, and determines that the program isn't trying to do anything that needs SYS_NICE after all. The kernel tells glib that everything is fine, and glib finishes setting up the thread pool.

At no point does anything even attempt to make any actual changes to the scheduling parameters. cups_browsed doesn't want to renice itself. It's just that, as part of the startup process, the SYS_NICE capability is tested, even though it's ultimately not needed.

Personally, I like Jamie's suggestion: mute the message using a "deny" rule, since it's understood and not causing any ill effects.

If users want to do this before it gets integrated (and I suggest it gets upstreamed to Debian, where that file is introduced), then create a file named /etc/apparmor.d/local/usr.sbin.cups-browsed with the contents "deny capability sys_nice," (including the comma).