App moved from core18 to core20 but apparmor is blocking it from running

[saa1box]

Hi,

I tryed to port my application from core 18 to core 20. After a succesfull build I tryed to run it on the virtual core and recived the following errors:

I tryied compiling and installing my app using the --devmode with the following result:

I tried disabling the apparmor to see if the problem is solved but i dont have to acces rights to do it.

Could you further advise me how to solve this problem? I am out of ideas...

[nickH]

Hi, 

I would suggest to look into your snapcraft.yaml file. 

With the release RM21.11 the automation-bundle slot got updated to v2. If you haven't done this already you have to change your parts and slots. You can see how in the snapcraft.yaml of a bundle-example in the SDK-V-0112 (e.g. here). 

Best regards

Nick

[saa1box]

Dear Nick,

I already tryed to update my snapcraft.yaml file but probably it still has mistakes.

For my project there are 2 important things: datalayer access (datalayer plug) and saving log files(active solution plug).

This is the snapcraft.yaml file i tryed to use(based on the source you shared with me) but produced the same error (snap.rexroth-deviceadmin.web denied by apparmor). Please advice me on how to modify it further.

name: endurance

version: "2.0.0"

grade: stable

summary: Endurance test

description: |

base: core20

confinement: strict

parts:

  bundle:

    source: ./generated/endurance

    plugin: dump

    organize:

     '*' : endurance/${SNAPCRAFT_PROJECT_NAME}/

slots:

  endurance:

    interface: content

    content: endurancedata

    source:

      read:

        - $SNAP/endurance/${SNAPCRAFT_PROJECT_NAME}

plugs:

  active-solution:

    interface: content

    content: solutions

    target: $SNAP_COMMON/solutions

  datalayer:

    interface: content

    content: datalayer

    target: $SNAP_DATA/.datalayer

[nickH]

Hi, 

I forgot to ask. Is your app a realtime bundle? 

Or a normal non-realtime snap?

And just to make sure: 

• Your snap worked on version 1.10 before?
• What steps where you doing to update the snap to Version 1.12?
• Is your ctrlX CORE updated to Version 1.12?

Regards 

Nick

[saa1box]

Dear Nick,

This morning I realized that I didnt take enough time to look at this problem carefully.

What I found out is that the problem is already present when I only have the motion app installed on the system.

I performed a clean install of CTRLX Works with version 1.12.1. The error was not present at this point.

Than I installed motion app 1.12.0. After that the followin message started to appear:

[system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.9' (uid=0 pid=1403 comm="/snap/rexroth-deviceadmin/971/bin/wasp -config /va" label="snap.rexroth-deviceadmin.web (enforce)")

Sorry for missleading you with the original post, but I think the motion app might be the root of the problem.

Regards,

Adam

[nickH]

Hi Adam, 

I just tried it with a new installation and it works fine for me. 

Can you take a look into your system apps. It should look like this:

Further check your scheduler settings, after the installation it should look like this: 

Note: before the installation of the Motion app it has Callables "#placeholder#axisprofile" and "#placehoder#motion".

Finally have a look at your Date & Time settings, so you have the current date and time set, and into the Licenses. For ctrlX COREvirtual it looks like this: 

Regards

Nick 

[nickH · Accepted solution]

Hi Adam,

I got an update on your issue. 

The notification (apparmor="DENIED" operation="open" profile="snap.rexroth-deviceadmin.web" name="/snap/" pid=1495 comm="wasp" requested_mask="r" denied_mask="r" fsuid=0 ouid=0) in the Logbook appears because the DeviceAdmin-App has a bug. The App tries to access data outside of its own snap, which gets blocked by apparmor because of security violations. 

Other than notifications in the logbook this bug doesn't have any negative effect and can be ignored. Further this bug will get fixed with the next patch of the DeviceAdmin. 

Best regards

Nick