Interface request: "cups-control" on CUPS snap and including D-Bus

snapd
41

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.

42

@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?

43

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()?

44

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

45

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.

46

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.

47

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
48

Thanks, @jdstrand.
For your work on the interface, I have found out the following D-Bus relations:

cupsd:

  • Provides the services org.cups.cupsd.Notifier and com.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
49

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.

50

@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?

51

A couple of high priority items came in last week but are (mostly) complete now. I plan to start on this work this week.

52

@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.

53

It doesn’t, but thanks for the info since I can then develop with your latest code. I am >< close to starting on this. :slight_smile:

54

Renaming has ben done now in the OpenPrinting GitHub:

55

@jdstrand, @jamesh, I have posted the request for interface auto-connection for the CUPS Snap now.

1 Like