Hi Jamie,
Thanks for the detailed explanation, it's really helpful!
However, I am hesitated to package my example files in the snap, just
curious, what's the proper way to package a "development snap" which reads
user given files and requires root permission? For example, I'd like to
package necessary node.js components in a snap for developers to design
their node.js based BLE apps, I've add node, bleno and noble modules in a
snap, so the idea is to let the users create their own node.js sample apps
(under their $HOME) and invoke the node command in my snap to run their
sample apps. Since the bleno/noble node modules require root privilege for
accessing BLE, I used "sudo mysnap.node <sample_file_in_home>" to run the
snap command. But as you pointed out, the fsuid=0 but ouid=1000 which
prevents the sample file being read from the snap command?
Best Regards,
Tonny
On Tue, Feb 7, 2017 at 1:50 AM, Jamie Strandboge <ja...@canonical.com>
wrote:
> On Mon, 2017-02-06 at 23:10 +0800, Tonny Tzeng wrote:
> > Hi,
> >
> > The 'home' interface provides non-hidden files access to the snap defined
> > commands, but what if specific commands need to be run with 'sudo', how
> can
> > I read files from my user folder? For example, from below syslog, I run
> my
> > snap with 'sudo' to enable the bluetooth, but once I run the snap with
> > root, it can't access $HOME:
> >
> > audit: type=1400 audit(1486391164.744:1219): apparmor="DENIED"
> > operation="open" profile="snap.iotivity-smarthome-demo.node"
> > name="/home/tzeng/Workspace/node-examples/bluetooth/central-ess.js"
> > pid=6991 comm="node" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000
> >
> > Any pointers would be very appreciated. Thanks.
> >
>
> What is happening is that the home interface uses an AppArmor rule like
> this:
>
> owner @{HOME}/** rwk,
>
> The @{HOME} AppArmor variable expands to include /home/<user> and /root so
> the
> file paths aren't an issue, but the 'owner' match requires that the
> process' uid
> and the file's uid match, so the issue you are seeing is that the
> ownership is
> not matching[1].
>
> Keep in mind that while useful, the home interface grants a lot of access
> to the
> snap and in general for strict confinement, best practice would have you
> use
> SNAP_USER_DATA for data that is specific to a particular user (and use
> 'sudo -H'
> instead of 'sudo' so that the $HOME env var is set to /root). For data
> that is
> written by root but readable by others, use SNAP_DATA since it accessible
> by
> everything in your snap.
>
> It appears this is a demo snap-- I suggest putting your example files in
> your
> snap (ie, in $SNAP) and have all your commands look for them in $SNAP
> (you'll
> need to do this anyway since /home/tzeng/Workspace/node-examples/... only
> exists
> on your machine). For things that need read/write, put them in SNAP_DATA or
> SNAP_USER_DATA and have all your commands look for them there. If you want
> to
> share data between commands for different users, either put the files in
> /tmp
> (it is snap-specific and cleared on reboot) or create a persistent
> snap-specific
> shared directory in $SNAP_DATA (eg, mkdir -m 1777 $SNAP_DATA/tmp) and put
> them
> there.
>
> Hope this helps!
>
> [1]In general, it is best practice to avoid processing files that are under
> another user's control since those files could potentially be used to
> alter the
> behavior of the running process
>
> --
> Jamie Strandboge | http://www.canonical.com
>
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>
>
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
