Permissions and alias request for 'softmaker-office-21'

I uploaded rev. 1047 of SoftMaker Office 2021 in edge channel. It needs to be approved:

  1. Write permission needed for $SNAP_COMMON/SoftMaker folder.
  2. It would be good applications to have aliases ‘textmaker21’, ‘planmaker21’ and ‘presentations21’.

There are issues with associations and document icons too.

Hi - I went looking but couldn’t see any snap in the store called softmaker-office-21 - are you sure you have uploaded it or that this is the correct snap name?

Also snaps already have write permissions to $SNAP_COMMON so there is no need to request this or say use system-files etc to gain this permission - so please remove this.

Finally, +1 from me for these aliases - they don’t appear to conflict with other applications.

It is in edge channel, marked as private. I use

layout:
  /etc/SoftMaker:
    bind: $SNAP_COMMON/SoftMaker

but when I try to write to /etc/SoftMaker from inside the app I receive a message box said there are no permissions.

+1 from me for the aliases, as well.

@alexmurray Would it be possible to expedite this?

Regarding needing to write to /etc/SoftMaker - can you please provide more details on why this is required? Normally a user application is not able to write to /etc anyway as this is owned by root - why does your snap need to write to this location?

Regarding the alias request - +2 votes for, 0 votes against, auto-aliases for textmaker21, planmaker21 and presentations21 for softmaker-office-21 - however I still can’t see this snap in the store - are you sure it has been uploaded and are you sure this is the right snap name? @Igor can you see the snap in the store?

As I said the package is in edge channel and marked as private. It is still not ready to be published, I have other problems, e.g. when using gtk2 file system dialogs applications hang on “File/Save as” dialog (if you have access to the package you can try this by yourself - install it, open an app from command line and try to save the file), have problems with document icons and file associations (to make applications default for supported document types) etcetc.

The folder /etc/SoftMaker is needed to keep some common data, e.g. hunspell dictionaries which users download. When one user of multiuser system downloads a dictionary it is stored in this place, and other users can use it too.

In Windows we use c:\programdata folder for this purpose. In Linux we had to create such a folder in /etc in our post-install script from .deb package. This was done due to customer requests and IMO is good to be kept.

@alexmurray Just to add to what @hristov wrote, SoftMaker needs to be able to create the /etc/SoftMaker dir, as well as write to it (and read), as it will contain important cross-session, cross-user info (which may also be shared and used by non-snap editions of SoftMaker).

The snap will also need file association for its specific file types.

ok - I am still confused since as a store reviewer I can normally see all snaps in the store even when they are private - @roadmr are you able to see this snap by any chance?

If you need access to the real /etc/SoftMaker then you should use system-files for this rather than a layout and request the write permission.

Here is a screenshot of my profile page:

@alexmurray you could not see the snap since as per the shared screenshot the snap name is softmaker-office-2021 instead of softmaker-office-21 as indicated :).

I am +1 as well for granting the requested aliases. +3 votes for, 0 votes against, granting the textmaker21, planmaker21 and presentations21 aliases to softmaker-office-2021. This is now live.

@hristov please work on moving from using a layout to plugging system-files and let us know if you have any questions.

Thanks

$SNAP_COMMON/SoftMaker

works for now after the folder was created in install hook. Current problem is gtk2/gtk3 file saving dialog - an assertion fails there and the app hangs. Don’t know if this is my or your (snap team) problem. Or both. But the fact is that without snap same executable works without problems.

When you see this assertion failure and application hang, are there any associated AppArmor DENIAL messages in dmesg or similar? Can you please post the output of the assertion failure too as this may allow us to help figure out what the issue is? Thanks.

No. Here is the assertion:

(textmaker:30268): Gtk-CRITICAL **: 11:07:36.726: gtk_file_chooser_get_filter: assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed
(textmaker:30268): Gtk-CRITICAL **: 11:07:36.726: gtk_file_chooser_get_filter: assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed
(textmaker:30268): Gtk-CRITICAL **: 11:07:36.726: gtk_file_chooser_get_filter: assertion 'GTK_IS_FILE_CHOOSER (chooser)' failed

and here is /var/log/syslog:

May 30 11:07:19 Mint-VM kernel: [19019.017347] kauditd_printk_skb: 1059 callbacks suppressed
May 30 11:07:19 Mint-VM kernel: [19019.017349] audit: type=1400 audit(1653901639.207:18470): apparmor="ALLOWED" operation="open" profile="snap.softmaker-office-2021.textmaker" name="/proc/30268/mountinfo" pid=30268 comm="gmain" requested_mask="r" denied_mask="r" fsuid=1001 ouid=1001
May 30 11:07:19 Mint-VM kernel: [19019.017705] audit: type=1400 audit(1653901639.207:18471): apparmor="ALLOWED" operation="open" profile="snap.softmaker-office-2021.textmaker" name="/etc/fstab" pid=30268 comm="textmaker" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0
May 30 11:07:19 Mint-VM kernel: [19019.017708] audit: type=1400 audit(1653901639.207:18472): apparmor="ALLOWED" operation="open" profile="snap.softmaker-office-2021.textmaker" name="/proc/30268/mountinfo" pid=30268 comm="textmaker" requested_mask="r" denied_mask="r" fsuid=1001 ouid=1001
May 30 11:07:19 Mint-VM kernel: [19019.020082] audit: type=1400 audit(1653901639.211:18473): apparmor="ALLOWED" operation="open" profile="snap.softmaker-office-2021.textmaker" name="/run/mount/utab" pid=30268 comm="textmaker" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0
May 30 11:07:19 Mint-VM kernel: [19019.022593] audit: type=1326 audit(1653901639.215:18474): auid=4294967295 uid=1001 gid=1001 ses=4294967295 pid=30268 comm="textmaker" exe="/snap/softmaker-office-2021/x1/usr/share/office2021/textmaker" sig=0 arch=c000003e syscall=314 compat=0 ip=0x7f51f22ff73d code=0x7ffc0000
May 30 11:07:19 Mint-VM kernel: [19019.022797] audit: type=1326 audit(1653901639.215:18475): auid=4294967295 uid=1001 gid=1001 ses=4294967295 pid=30268 comm="textmaker" exe="/snap/softmaker-office-2021/x1/usr/share/office2021/textmaker" sig=0 arch=c000003e syscall=314 compat=0 ip=0x7f51f22ff73d code=0x7ffc0000
May 30 11:07:19 Mint-VM kernel: [19019.022999] audit: type=1326 audit(1653901639.215:18476): auid=4294967295 uid=1001 gid=1001 ses=4294967295 pid=30268 comm="textmaker" exe="/snap/softmaker-office-2021/x1/usr/share/office2021/textmaker" sig=0 arch=c000003e syscall=314 compat=0 ip=0x7f51f22ff73d code=0x7ffc0000
May 30 11:07:19 Mint-VM kernel: [19019.163553] audit: type=1326 audit(1653901639.355:18477): auid=4294967295 uid=1001 gid=1001 ses=4294967295 pid=30268 comm="textmaker" exe="/snap/softmaker-office-2021/x1/usr/share/office2021/textmaker" sig=0 arch=c000003e syscall=314 compat=0 ip=0x7f51f22ff73d code=0x7ffc0000
May 30 11:07:19 Mint-VM dbus-daemon[705]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.201' (uid=1001 pid=30268 comm="/snap/softmaker-office-2021/x1/usr/share/office202" label="snap.softmaker-office-2021.textmaker (complain)")
May 30 11:07:19 Mint-VM kernel: [19019.256119] audit: type=1400 audit(1653901639.447:18478): apparmor="ALLOWED" operation="open" profile="snap.softmaker-office-2021.textmaker" name="/proc/30268/mountinfo" pid=30268 comm="textmaker" requested_mask="r" denied_mask="r" fsuid=1001 ouid=1001
May 30 11:07:19 Mint-VM kernel: [19019.284948] audit: type=1400 audit(1653901639.475:18479): apparmor="ALLOWED" operation="open" profile="snap.softmaker-office-2021.textmaker" name="/run/mount/utab" pid=30268 comm="textmaker" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0
May 30 11:07:19 Mint-VM systemd[1]: Starting Hostname Service...
May 30 11:07:19 Mint-VM dbus-daemon[705]: [system] Successfully activated service 'org.freedesktop.hostname1'
May 30 11:07:19 Mint-VM systemd[1]: Started Hostname Service.
May 30 11:07:31 Mint-VM kernel: [19031.483927] kauditd_printk_skb: 7 callbacks suppressed
May 30 11:07:31 Mint-VM kernel: [19031.483931] audit: type=1400 audit(1653901651.675:18487): apparmor="ALLOWED" operation="open" profile="snap.softmaker-office-2021.textmaker" name="/proc/30268/mountinfo" pid=30268 comm="textmaker" requested_mask="r" denied_mask="r" fsuid=1001 ouid=1001
May 30 11:07:31 Mint-VM kernel: [19031.488784] audit: type=1400 audit(1653901651.679:18488): apparmor="ALLOWED" operation="open" profile="snap.softmaker-office-2021.textmaker" name="/run/mount/utab" pid=30268 comm="textmaker" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0
May 30 11:07:36 Mint-VM systemd[974]: snap.softmaker-office-2021.textmaker.13c36002-757e-4fdf-b4aa-7e87d7434946.scope: Succeeded.
May 30 11:07:49 Mint-VM systemd[1]: systemd-hostnamed.service: Succeeded.

According to first lines of /var/log/syslog I should probably ask for read permission for /proc/**/mountinfo, /etc/fstab and /run/mount/utab.

BTW I made some work-around by using libgnome-desktop instead of libgkt-3 and now these dialogs can be used. The process is progressing.

So for access to /proc/**/mountinfo and /etc/fstab you can plug the mount-observe interface. At the moment this interface does not include access to /run/mount/utab however I think this would be appropriate to also be included in that interface as well so I will submit a PR to snapd to include this in a future update.

FYI PR submitted as https://github.com/snapcore/snapd/pull/11831

@hristov - the above PR has been approved/merged, and should be available in the edge channel - this should allow read access to /run/mount/utab using the mount-observe interface.

@hristov from what I can see there doesn’t look to be any action required on this request from our side as the snap does not appear to require the use of system-files anymore from what I can see. As such I am removing the request for system-files from our internal queue. Please let me know though if you still require this and we can reopen it. Thanks.