Use of sudo when building snaps

jamesbeedy · January 10, 2018, 7:08pm

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?

ogra · January 10, 2018, 7:12pm

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…

lonroth · January 10, 2018, 7:13pm

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.

jamesbeedy · January 10, 2018, 7:16pm

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

ogra · January 10, 2018, 7:20pm

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)

jamesbeedy · January 10, 2018, 7:25pm

and the permissions (everything owned by my user) https://paste.ubuntu.com/26361916/

and the error (this happens in the pcre building section of the nginx part) https://paste.ubuntu.com/26361926/

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

ogra · January 10, 2018, 7:30pm

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   libpcre.la     libpcreposix.la libpcrecpp.la '/usr/local/lib'
libtool: install: /usr/bin/install -c .libs/libpcre.so.1.2.9      /usr/local/lib/libpcre.so.1.2.9
/usr/bin/install: cannot remove '/usr/local/lib/libpcre.so.1.2.9': 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 / )

lonroth · January 10, 2018, 7:34pm

github.com

omnivector-solutions/snap-django-gunicorn-nginx/blob/master/snap/plugins/x-nginx.py#L166


    os.makedirs(self._nginx_part_dir, exist_ok=True)
    self._nginx_tar.download()
    self._nginx_install(builddir=self._nginx_part_dir)
def env(self, root):
    env = super().env(root)
    env.append('PATH={}:{}'.format(
        os.path.join(root, 'bin'), os.environ['PATH']))
    return env
def _pcre_install(self, builddir):
    self._pcre_tar.provision(
        builddir, clean_target=False, keep_tarball=True)
    self.run(['./configure', '--prefix={}'.format(self.partdir)], cwd=builddir)
    self.run(['make', '-j{}'.format(self.parallel_build_count)],
             cwd=builddir)
    self.run(['make', 'install'], cwd=builddir)
def _zlib_install(self, builddir):
    self._zlib_tar.provision(
        builddir, clean_target=False, keep_tarball=True)

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

jamesbeedy · January 10, 2018, 7:35pm

oh no … I feel so silly.

@ogra thanks for chiming in/pointing this out

kyrofa · January 10, 2018, 7:41pm

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

sparkiegeek · January 11, 2018, 9:49am

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

popey · January 11, 2018, 10:02am

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.

svet · January 11, 2018, 10:29am

I’ve been running with sudo as a (reluctant, but I figured benign) workaround to an issue similar to the one described here https://bugs.launchpad.net/snapcraft/+bug/1676684.

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/python.py", line 368, in build
    self._fix_permissions()
  File "/usr/lib/python3/dist-packages/snapcraft/plugins/python.py", line 345, in _fix_permissions
    _replicate_owner_mode(os.path.join(root, filename))
  File "/usr/lib/python3/dist-packages/snapcraft/plugins/python.py", 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/libnss_compat.so'

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/libnss_compat.so.2.

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?

cratliff · January 11, 2018, 3:44pm

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.

kyrofa · January 11, 2018, 6:42pm

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?

kyrofa · January 11, 2018, 6:43pm

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).

cratliff · January 11, 2018, 7:12pm

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

ogra · January 11, 2018, 9:41pm

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

kyrofa · January 11, 2018, 9:45pm

Here’s my official guidance:

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

jamesbeedy · January 12, 2018, 4:16am

@ogra I’ve made the modifications to set --prefix equal to self.partdir as can be seen here https://github.com/omnivector-solutions/snap-django-gunicorn-nginx/blob/configure_prefix/snap/plugins/x-nginx.py#L169

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 https://paste.ubuntu.com/26369907/ when trying to build w/o sudo.

Any idea what may be causing ^?