Restrictive umask and permissions may cause a built snap to be unusable

[Bruno Nova]

I use the umask 007 in my system.

When I built a test package with snapcraft and installed it in a Snappy Core system, most of the files and folders of the package where not accessible by the "other" users, and thus I couldn't run the binaries (no permission).

I think snappy/snapcraft should make some permissions/umask checks.

Maybe snapcraft or "snappy build" should check the permissions of all packaged files and directories (like how the Debian build tools do), and either correct the permissions or warn the user about files that have strange permissions.
Snapcraft could also enforce an umask of 002 or 022.

[Mark Shuttleworth (sabdfl)]

Yes, it makes sense that snapcraft check the package for usefulness,
good catch, thank you!

[Sergio Schvezov (sergiusens)]

For 15.04 this is more of a snappy project problem. For 16.04 it is all snapcraft.

[Michael Vogt (mvo)]

I agree that this is a very useful thing to check in snapcraft and in the reviewers tools. However it feels like snappy itself should not force a policy for the snap content, there may be legit use-cases for restrictive permissions. I close the task for snappy itself, please reopen with a rational if you feel snappy itself should check this too.

[Kyle Fazzari (kyrofa)]

This may be irrelevant now that we're based on squashfs and using -no-xattrs. This needs to be revisited.

[Leon (leonbo)]

This issue stil exists:

http://paste.ubuntu.com/21187624/

Working version: http://paste.ubuntu.com/21186621/

[Leon (leonbo)]

For a discussion about that, see: https://irclogs.ubuntu.com/2016/07/27/%23snappy.txt (around 20:08, <LBo> & <kyrofa>).

[Jamie Strandboge (jdstrand)]

I think it would be useful for snapcraft to perform a check for usefulness and perhaps give feedbackc during 'snapcraft build'. While the review tools have some checks for particularly weird permissions, they can't second-guess the developer's intent who may have intentionally set the permissions. I'm going to close the review tools bug as "Won't Fix" for now, but I can re-open it if needed.

[Sergio Schvezov (sergiusens)]

consistent build environments make this a non issue for the general case