Access to procfs, configfs, sysfs

Apparmor in strict confinement denies access to proc and configfs. (I haven’t tried yet but sysfs maybe as well?)

Are there any means to access these filesystems in strict mode?

Hello! Full access to these filesystems is not likely to be allowed but there may be some valid use cases where accessing certain file paths is acceptable. We’ll need more information about which paths you’re accessing and how you’re interacting with them (read-only or are you also writing?).

1 Like

Yes, many accesses are offered through various interfaces. For example, hardware-observe and system-observe. I suggest that you use the snappy-debug tool (snap install snappy-debug && sudo scanlog), exercise your application and see what it has to say. If there are accesses you need, please report them.

  1. By default configfs is not mounted, so I need to do it from some snap because this is the only customization point for Ubuntu Core.
    a) If you try to /bin/mount from shell script than this gives immediately DENIED with suggestion to “adjust snap to ship ‘mount’”. It seems like a dummy message which will never help, isn’t it?
    b) /etc/fstab is readonly
    c) trying to call mount() syscall programmatically will give a SECCOMP deny, I suppose?

  2. And then configure the system with configfs which requires write access to it.

I have a similar problem:

Log: apparmor="DENIED" operation="open" profile="snap.usb-reset.usb-reset" name="/sys/bus/usb/devices/" pid=21851 comm="usb-reset" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
File: /sys/bus/usb/devices/ (read)
* adjust program to not access '/sys/bus/usb/devices/'
* add one of 'camera, raw-usb' to 'plugs'

The suggestion is to add raw-usb, but that is already in plugs. I’ve also tried hardware-observe. I’m a beginner, so it’s entirely possible I’m doing something stupid.

Code and snapcraft.yaml are at

did you also connect it using snap connect ? (i dont think raw-usb is allowed to auto-connect)

Right, no I hadn’t. That works now, thanks very much.

1 Like

@ogra, AppArmor doesn’t let me access /proc/asound

= AppArmor =
Time: Jul 25 09:56:41
Log: apparmor="ALLOWED" operation="open" profile="snap.mainc.mainc" name="/proc/asound/card0/pcm0p/sub0/hw_params" pid=1324 comm="mainc" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
File: /proc/asound/card0/pcm0p/sub0/hw_params (read)
* adjust program to not access '@{PROC}/asound/card0/pcm0p/sub0/hw_params'

:alsa is connected as well as :hardware-observe and :system-observe.

Seems like /proc/asound is not part of any interface? How to get there?

i guess it should be added to the alsa interface … @jdstrand ?

Sounds quite reasonable it seems.

Yes, this is fine. I’ll create a PR.

@jdstrand, @tyhicks, guys, how about configfs? Automount it on boot and write access to configure it?

It sounds like the proper way to handle that would be to teach Ubuntu Core itself to have the filesystem mounted, and then have interfaces that allow specifying the specific configuration settings desired. If we open up for a snap to edit fstab and mounting filesystems arbitrarily, then there’s not much point in having it confined anymore.

ogra@pi3:~$ mount|grep config
configfs on /sys/kernel/config type configfs (rw,relatime)

The configfs is always mounted (and has been since day one on the images, thats an ubuntu default), i’m not sure what image @denis uses, i see it mounted on all devices…

There is no interface allowing any access though.

The /proc/asound fixes will be in 2.27.

1 Like

As for configfs, I think we need to think about specific accesses like we do /proc and /sys rather than a global ‘all configfs’. What specific paths are you wanting to access within configfs?

I also think that the snap itself shouldn’t be the one doing the mounting/unmounting. If it doesn’t automount upon access, we could make snapd mount it upon interface connection and ensure it is mounted on reboot, similar to how snapd handles kernel modules.

1 Like

@jdstrand, I use configfs to control libcomposite which is used to combine several USB peripheral functions on one USB peripheral controller. For example to have USB Ethernet + USB Mass Storage. Or Audio + HID. Or Video + Audio + HID. Or custom functions with their corresponding kernel modules.

With configfs you can do it dynamically. For example, like in any smartphone, a user enters passcode, turns on mass storage function, copies files over the USB to PC and disables this function for security reasons.

As an Option 1 there could be a place to control it statically, once for every boot, but even for that there is no place. Everything is read only. But still in general dynamic control is more interesting.

The path is: $CONFIGFS_HOME/usb_gadget/
You start by creating a new USB gadget:

mkdir $CONFIGFS_HOME/usb_gadget/g1

And then you write to its internal structure.

@ogra, @niemeyer, indeed now I see it mounted after clean reboot with mount snap disabled. Thanks for pointing it out. I clearly remember once it didn’t appear somehow and I decided it’s permanent behavior.

configfs on /sys/kernel/config type configfs (rw,relatime)

OOOOH! i would love to have a libcomposite interface !!!

(i was pondering to enable the serial gadget by default in our official images since a while, sadly the OTG data path is not wired up on the normal raspberry pi miniUSB sockets (only on the pi zero) which had me drop that idea again)

1 Like

I’ve not used libcomposite or configfs before but have read While mkdir/rmdir manage the configuration, the directories being created and removed are backed by kernel modules and specific paths. You have at a high-level identified the following:

  • USB Ethernet
  • USB Mass storage
  • Audio
  • HID
  • Video

These could perhaps be mapped to specific existing interfaces:

  • USB Ethernet (network-control)
  • HID (hidraw)
  • audio (alsa?)

and perhaps a couple of new interfaces:

  • usb-mass-storage-control
  • video-control

On the other hand, if this is all being driven by libcomposite, we could do as @ogra implied and create a libcomposite interface (or maybe libcomposite-support) and let it write to configfs for all directories it supports.

In other words, we need a bit more information before we can settle on a design and implementation. Would you be able to provide that information?

1 Like

Details around gadget/composite are at:

All our core kernels currently ship with a libcomposite module …

(my personal interest was towards a serial gadget setup so you dont need a serial cable but can use a simple microUSB one for console-conf, but this would be more a core snap feature than something an external snap could provide)