Use of sudo when building snaps


I’ve ran into a myriad of questions from people lately asking why the snapcraft command has to be ran as sudo. I can think of a number of reasons why to tell them, but I thought someone here might be able to give more educated/explicit/detailed answer then myself.

Any takers?


err, you definitely do not want to use sudo with snapcraft unless you build a snap that actually requires it (and even then you want to use rather a container) …

imagine you make a typo in the install parts, the build might accidentially dump stuff into / on your host … build-packages will be installed on the host machine directly etc etc …

like with deb packages (where you use fakeroot to not have to actually use the root user) you should never build with snapcraft using root or sudo…


I’m one of those with concerns about having to build a snap with root. I do however might have too little knowledge about snaps to understand this yet.

However, I see before me multiuser systems where people have to have “sudo” rights to be able to operate a build process. In that, exposing various dangers, such as “rm -rf /*”, etc, etc, etc.

Further, the buildprocess could create files that will be owned by “root”, which the normal user wont be able to remove unless “sudo rm /*” is in the scope. There is only disasters waiting down that path.


oh man :confused: - I’ve never been able to get a successful build w/out using sudo, I must be doing something entirely wrong.


yes, what snap is that, do you have any link to the source tree ?

there are only a few snaps that actually require root, namely the core snap (because it creates a rootfs to be able to boot from) and the official kernel snap (which re-packs the deb based kernel into snap using a chroot), these should be the only cases where root is actually needed (and even there you would build in a container using “snapcraft cleanbuild”, so the root part becomes a moot point)


and the permissions (everything owned by my user)

and the error (this happens in the pcre building section of the nginx part)

Possibly I have something in tmp or a cache somewhere that is owned by root that the build process is trying to access.


well, there is something wrong and the snap tries to install something to /usr/local as you can see …

 /bin/mkdir -p '/usr/local/lib'
 /bin/bash ./libtool   --mode=install /usr/bin/install -c '/usr/local/lib'
libtool: install: /usr/bin/install -c .libs/      /usr/local/lib/
/usr/bin/install: cannot remove '/usr/local/lib/': Permission denied

so in this case not using sudo actually saves your from messing up your PC … fix the install location of your snap to install to $DESTDIR (which points to ./parts/<partname>/install usually and not to something on / )


How do one tell snapcraft to build into some other directory from the above ?


oh no … I feel so silly.

@ogra thanks for chiming in/pointing this out


Indeed, as @ogra says, if you’re running snapcraft with sudo, something is wrong.


Hear hear! Maybe snapcraft should detect it and bail out early?


I run snapcraft as root (not under sudo) all day by virtue of using snapcraft cleanbuild and manually inside lxc containers. So if you do consider doing this check, please don’t break running snapcraft as root.


I’ve been running with sudo as a (reluctant, but I figured benign) workaround to an issue similar to the one described here

In my case, when running as a regular user, I get the following permissions error during the install stage:

  File "/usr/lib/python3/dist-packages/snapcraft/plugins/", line 368, in build
  File "/usr/lib/python3/dist-packages/snapcraft/plugins/", line 345, in _fix_permissions
    _replicate_owner_mode(os.path.join(root, filename))
  File "/usr/lib/python3/dist-packages/snapcraft/plugins/", line 536, in _replicate_owner_mode
    os.chmod(path, new_mode)
PermissionError: [Errno 1] Operation not permitted: '/home/<username>/<snapname>/parts/<partname>/install/usr/lib/x86_64-linux-gnu/'

I’ve only pasted the last few lines here, but it’s basically a permissions error when attempting to chmod a file that’s actually for some reason a symlink to /lib/x86_64-linux-gnu/

The above permissions error only occurs if I include libsnmp-dev under stage-packages in my snapcraft.yaml - which is similar behavior to the bug report on Launchpad that I linked to.

Is there a reasonable way to fix this behavior (e.g. by using a custom install script), or am I best off just doing a cleanbuild in a container?


I’m having a similar issue causing me to, also reluctantly, run snapcraft with sudo. It is identical to svet’s problem just with a different lib. I didn’t think this problem would be that prevalent, but I wonder if there is a way to work around this since it could get onerous to have to fix any package you install using symlinks to /lib. Looking through the parts directory for just the 6 or so pip packages I’m installing it looks like a good number of the libraries point to /lib instead of ./lib.


Yeah both of those sound like a bug in snapcraft. The one referenced I can’t reproduce-- @cratliff or @svet, can one of you please log a bug with a YAML that reproduces the issue?


Notice I said “something is wrong” not necessarily “you’re doing it wrong.” There are cases (bugs in the packaging, bugs in snapcraft, etc.) where this ends up being needed for some reason. However, if it is, it’s probably something that should be fixed somewhere (perhaps in snapcraft, like the issues just mentioned).


I attached the snapcraft.yaml to the same bug referenced earlier since I’m seeing a very similar stack trace on the output.


No, it definitely should not, there are some very valid cases where sudo is needed … like building a core snap where you run debootstrap and create a to-be-used /dev dir with root owned device nodes … or re-packing a deb from the archive inside a chroot to turn it into a snap … being wrong in 98% of the cases still leaves 2% where it is totally fine to use sudo :wink:


Here’s my official guidance:

“If you’re not @ogra, and you find yourself using sudo, talk to us.” :stuck_out_tongue:


@ogra I’ve made the modifications to set --prefix equal to self.partdir as can be seen here

Hopefully this is along the lines of what you are talking about.

I seem to be getting past my previous error (my nginx part builds w/o sudo, hurray!), although I’m now hitting another permissions error in my django-gunicorn part when trying to build w/o sudo.

Any idea what may be causing ^?