@jdstrand, @ijohnson, libapparmor used in the cupsd patch needs to access /proc/PID/attr/current. Is “system-observe” the correct interface for that?
@jamesh, how is PulseAudio doing that?
This and other accesses will need to be in the updates to the cups-control interface that I will make. For now, please use --devmode when installing your snap. I’ll post something here when there is something to test.
As for pulseaudio, the pulseaudio snap does not have the mediation patches and so the existing pulseaudio slot policy is sufficient. That policy will need updating if/when the pulseaudio snap is updated with the mediation patches.
@jdstrand do you think the cups-control interface should use an attribute that only the cups snap gets to use to get this access since it is somewhat privileged and we may not necessarily want to give it out to any snaps that already are using cups-control ?
We’ll ensure the base implementation is such that cups-control operates like other slot implementations like it so that declaring slots: [ cups-control ] gets flagged for manual review by the store. This is a common pattern within the base declaration and snap declaration for slot implementations.
@jdstrand, @ijohnson, @jamesh, I have done another commit to the printing-stack-snap repo now to assure that the Snap works with the new CUPS patch and also to make sure that if the Snap is started with no other CUPS (from .deb for example) running, that the Snap’s CUPS uses the standard domain socket (/ver)/run/cups/cups.sock and port 631.
With this you should be able to do all tests for the interface changes in snapd.
Please read also the description of my commit, to see what are all the things I changed.
2 Likes
I have continued the development of the Snap and did some further commits to the GitHub. Then I have installed in restricted mode:
sudo snap install --dangerous printing-stack-snap_0.1.0_amd64.snap
(using --dangerous instead of --devmode). Then I have tried out the checking of admin tasks again and ran
printing-stack-snap.lpadmin -p snap-label -E -v ipp://Label%20Printer._ipp._tcp.local/ -m driverless:ipp://Label%20Printer._ipp._tcp.local/
Note that the URI must exist in your network. To find suitable URIs, run the command
driverless
The print queue is created (it should even if all is working correctly), but in the error_log, the file
/var/snap/printing-stack-snap/current/var/log/error_log
I saw that it is not working correctly:
D [14/May/2020:19:28:38 +0200] cupsdIsAuthorized: username="till"
D [14/May/2020:19:28:38 +0200] cupsdCheckAdminTask: Administrative task
D [14/May/2020:19:28:38 +0200] cupsdCheckAdminTask: Clent connecting via domain
socket, examining client process 1291963 ...
D [14/May/2020:19:28:38 +0200] cupsdCheckAdminTask: Checking whether client proc
ess is from a Snap ...
D [14/May/2020:19:28:38 +0200] cupsdCheckAdminTask: No AppArmor in use
D [14/May/2020:19:28:38 +0200] cupsdCheckAdminTask: Access granted
D [14/May/2020:19:28:38 +0200] snap-label device-uri: OK
I [14/May/2020:19:28:38 +0200] Setting snap-label device-uri to "ipp://Label%20P
rinter._ipp._tcp.local/" (was "file:///dev/null".)
You see the line with “No AppArmor in use”. This is wrong, as Snaps use AppArmor to make up the sandboxes. The line comes from the following piece of code in my patch (patches/cupsd-extra-check-for-admin-tasks-snap-cups-control.patch):
/* If AppArmor is not enabled, then we can't identify the client */
if (!aa_is_enabled())
{
cupsdLogMessage(CUPSD_LOG_DEBUG,
"cupsdCheckAdminTask: No AppArmor in use");
goto snap_check_done;
}
meaning that the function aa_is_enabled() does not see AppArmor.
@jdstrand, @jamesh, @ijohnson, how does PulseAudio handle this? Do I need to plug another interface? Or do I need access to certain system files.
@jdstrand, @jamesh, is the aa_is_enabled() function, which is supposed to only check whether AppArmor is in use, already needing to access /proc/PID/attr/current?
I have found this one in /var/log/syslog:
May 14 19:28:38 till-x1yoga kernel: [2848581.834271] audit: type=1400 audit(1589477318.439:2958705): apparmor="DENIED" operation="open" profile="snap.printing-stack-snap.cupsd" name="/proc/1283371/mounts" pid=1283371 comm="cupsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
with 1283371 being the PID of the Snap’s cupsd. Is this caused by aa_is_enabled()?
you can try adding the mount-observe interface to your snap and see if it works then. I don’t personally know how aa_is_enabled() works
aa_is_enabled() simply tries to see if /sys/kernel/security/apparmor is around and it does that by looking at /proc/mounts first (a symlink to /proc/self/mounts):
openat(AT_FDCWD, "/proc/mounts", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "sysfs /sys sysfs rw,nosuid,nodev"..., 1024) = 1024
stat("/sys/kernel/security/apparmor", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
So, ‘yes’ for now you need to plugs mount-observe, but we will probably instead want to add that to the slot apparmor policy for cups-control.
See https://gitlab.com/apparmor/apparmor/-/blob/master/libraries/libapparmor/src/kernel.c#L58 for details.
Yes, plugging mount-observe I get past aa_is_enabled() but the next check, aa_gettaskcon() fails:
if (aa_gettaskcon(client_pid, &context, NULL) < 0)
{
cupsdLogMessage(CUPSD_LOG_DEBUG,
"cupsdCheckAdminTask: AppArmor profile could not be retrieved for client process - Error: %s",
strerror(errno));
goto snap_check_done;
} else
This is because of no permission to access /proc/PID/attr/current as you mentioned earlier.
Yes, this is the point at which you should install your snap in devmode and keep working. I will then take up your snap and update the cups-control interface accordingly.
(FYI, I plan to start on my part next week)
1 Like
Thanks, @jdstrand.
For your work on the interface, I have found out the following D-Bus relations:
cupsd:
- Provides the services
org.cups.cupsd.Notifierandcom.redhat.PrinterSpooler - Consumes the service
org.freedesktop.ColorManager
cups-browsed
- Consumes the service
org.cups.cupsd.Notifier
All mentioned D-Bus services are on the system bus.
1 Like
Note also that applications which print often consume one or another of the two system bus D-Bus services org.cups.cupsd.Notifier and com.redhat.PrinterSpooler to get notified about progress of the job.
@jdstrand, any news on the interface?
@jdstrand, @ijohnson, @jamesh, I have found a problem preventing the CUPS web interface from working, will this also have some influence on the interface? Or will the CUPS snap need to plug a certain interface?
A couple of high priority items came in last week but are (mostly) complete now. I plan to start on this work this week.
@jdstrand, I do not know whether it is relevant for the development of the new CUPS Snap interfaces, the CUPS Snap will be renamed, from “printing-stack-snap” to “cups”, and the GitHub repository at OpenPrinting will be named “cups-snap”.
I have already reserved the name “cups” in the Snap Store.
It doesn’t, but thanks for the info since I can then develop with your latest code. I am >< close to starting on this. 
Renaming has ben done now in the OpenPrinting GitHub:
@jdstrand, @jamesh, I have posted the request for interface auto-connection for the CUPS Snap now.
1 Like