Approved. Note you’ll still need to release it to a channel.
Dear @reviewers,
Not sure if that’s the right place to ask, but I’m having troubles with home interface here:
1.enonic snap is invoked, creates a folder (i.e myproject) inside user home folder and puts a file named enonic.toml inside it
2. when enonic snap is run next time it tries to read that file but is denied permissions, although the file has 777 set
Therefore it looks to me that snap wrapper forbids that operation, but isn’t it the sole purpose of home interface ?
If not, how this can be achieved ?
Thanks in advance !
Do you still have all the interfaces connected for your snap between the first and second invocation? What does snap connections enonic show?
Also, when you run the second time, do you see any denials in the system journal with journalctl -e --no-pager | grep DENIED?
Nothing was done in regards to interfaces between the 2 invocations.
snap connections enonic prints out:
Interface Plug Slot Notes
home enonic:home :home -
network enonic:network :network -
network-bind enonic:network-bind :network-bind -
personal-files enonic:dot-enonic :personal-files -
journalctl -e --no-pager | grep DENIED prints out:
Aug 08 17:03:49 anatoly-HP-Spectre-x360-Convertible-15-ch0xx audit[25974]: AVC apparmor="DENIED" operation="open" profile="snap.enonic.enonic" name="/home/anatoly/workspace/enonic/projects/myproject/enonic.toml" pid=25974 comm="enonic" requested_mask="rc" denied_mask="rc" fsuid=0 ouid=1000
Aug 08 17:03:49 anatoly-HP-Spectre-x360-Convertible-15-ch0xx kernel: audit: type=1400 audit(1565273029.980:55): apparmor="DENIED" operation="open" profile="snap.enonic.enonic" name="/home/anatoly/workspace/enonic/projects/myproject/enonic.toml" pid=25974 comm="enonic" requested_mask="rc" denied_mask="rc" fsuid=0 ouid=1000
Ouch ! Am I correct that apparmour is the one to blame here ?
This indicates that the file was created with owner uid 0, i.e. root and is being attempted to access by uid 1000, i.e. your normal user. Did you perhaps run the first command as sudo and the second one not as sudo?
Spot on, @ijohnson !
It was vice versa actually, but that is likely the cause.
Can’t tell for sure now, because running enonic without sudo has some difficulties finding JAVA_HOME, but that is a whole new story.
Thanks a lot for super snappy and helpful responses !
Ah yes, you’re correct it was created by your normal user and wasn’t accessible by root. If for some reason you do need to access the normal user’s $HOME from root, you can do so with the home plug’s read attribute set to all, like so:
plugs:
home:
read: all
However this will also require a store assertion (can be requested from this topic again).
We fixed JAVA_HOME error and It now works like a charm everywhere we tested except linux mint !
Mint fails with the following journal entry when trying to execute server.sh file to start the web-server:
[ 659.714519] audit: type=1400 audit(1568036215.389:83): apparmor="DENIED" operation="exec" profile="snap.enonic.enonic" name="/home/anatoly/.enonic/distributions/enonic-xp-linux-sdk-7.1.0-B3/bin/server.sh" pid=4298 comm="enonic" requested_mask="x" denied_mask="x" fsuid=1000 ouid=1000
Have you seen that before @ijohnson ?
AFAIK, I think that is expected because I think the personal-files interface is intended to allow reading and writing of files, not executing files from the dotfiles directory. @jdstrand is that accurate?
That’s correct. The personal-files and system-files interfaces are designed to give read or read/write access to files/directories as opposed to creating new work directories and the like.
In this particular case, I would suggest that the snap create a symlink from ~/.enonic/distributions to $SNAP_COMMON/dot-eonic/distributions or similar.
1 Like
Tried your suggestion with symlink but with not much luck 
Had to use $SNAP_USER_COMMON instead of $SNAP_COMMON though because the latter is owned by root.
Tried both hardlinking and softlinking $SNAP_USER_COMMON/dot-enonic to ~/.enonic.
Got following journal entry for a softlink (that did’t differ much from executing the bash script directly):
[23448.580537] audit: type=1400 audit(1568902184.524:384): apparmor="DENIED" operation="capable" profile="/snap/core/7713/usr/lib/snapd/snap-confine" pid=2820 comm="snap-confine" capability=4 capname="fsetid"
[23673.320116] audit: type=1400 audit(1568902409.264:385): apparmor="DENIED" operation="exec" profile="snap.enonic.enonic" name="/home/anatoly/.enonic/distributions/enonic-xp-linux-sdk-7.1.0/bin/server.sh" pid=3351 comm="enonic" requested_mask="x" denied_mask="x" fsuid=1000 ouid=1000
Also tried making a symlink to bash script directly that failed with similar error.
And here is what I got when trying to make a hardlink:
[24943.377804] audit: type=1400 audit(1568903679.263:436): apparmor="DENIED" operation="capable" profile="/snap/core/7713/usr/lib/snapd/snap-confine" pid=4807 comm="snap-confine" capability=4 capname="fsetid"
[24943.594068] audit: type=1400 audit(1568903679.479:437): apparmor="DENIED" operation="link" profile="snap.enonic.enonic" name="/home/anatoly/snap/enonic/common/dot-enonic" pid=4807 comm="enonic" requested_mask="xm" denied_mask="xm" fsuid=1000 ouid=1000 target="/home/anatoly/.enonic"
Which direction are you creating the link? I think you try making a symlink from inside ~/.econic to $SNAP_USER_COMMON/dot-enonic, the other way around won’t work.
I think I’m linking it the other way around because I want to execute script from /home/anatoly/.enonic/distributions/enonic-xp-linux-sdk-7.1.0/bin/server.sh.
So if I make ~/.enonic -> $SNAP_USER_COMMON/dot-enonic what will be the script path to execute ?
I haven’t tried yet, but yes I think that should work
It looks that I forgot to thank you guys, symlink did the trick ! 
I also have another request here 
We have extended the functionality of the app and it allows to build those projects I described above.
Project is built with gradle, which is java build and dependency management tool.
CLI just calls gradlew deploy under the hood and deploys it to the configured sandbox.
But because of the fact that gradle stores downloaded dependencies in ~/.gradle folder, we need to have WRITE access to it (for writing lock file as well as downloading deps). We don’t write anything there manually – it’s all done by gradle.
Here is what happens now:
Exception in thread "main" java.lang.RuntimeException: Could not create parent directory for lock file /home/anatoly/.gradle/wrapper/dists/gradle-5.3-bin/9tevgwefmd5lgaxkzkt5jgvch/gradle-5.3-bin.zip.lck
In addition to that gradle is capable of using maven repo stored in ~/.m2 folder.
And we use that option too, but we hopefully need only READ access to that folder.
So to sum it all up we would like to have:
- RW access to
~/.gradle - R access to
~/.m2
Let me know if you have any questions and Thanks in advance !
I will defer to @reviewers, but yes the process should be the same, it’s possible your request is in the queue of requests to process, aiui the team doing reviews has been a bit busier than usual as of late, but hopefully someone can comment soon for your new request.
Apologies this request got missed since it reused the old thread - I have added a task for our @reviewers to follow up on these additional paths.
From my point of view as a reviewer, enonic is not the clear owner of ~/.gradle and so I would be hesitant to grant RW access for this - and for the same reason I am not sure about ~/.m2 either - would it be possible to use the snap-specific /home/user/snap/enonic/<revision>/.gradle etc for these? Then since this is private to enonic there is no chance for conflicting with a native version of gradle etc that might be installed on the same machine and causing conflict if both try and use ~/.gradle in incompatible ways.