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).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1897369
Title:
apparmor: Allow cups-browsed to change nice value (CAP_SYS_NICE)
Status in cups package in Ubuntu:
Confirmed
Bug description:
In Ubuntu 20.04.1 with *cups-browsed* 1.27.4-1, apparmor prevents
`/usr/sbin/cups-browsed` to change its nice value.
$ sudo dmesg | grep apparmor
[541870.509461] audit: type=1400 audit(1600898428.089:60):
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed"
pid=62030 comm="cups-browsed" capability=23 capname="sys_nice"
[628298.779668] audit: type=1400 audit(1600984854.115:61):
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed"
pid=66850 comm="cups-browsed" capability=23 capname="sys_nice"
[714667.424963] audit: type=1400 audit(1601071220.527:62):
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed"
pid=76828 comm="cups-browsed" capability=23 capname="sys_nice"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1897369/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
