Is snap the right technology for a server application?

1

I’m trying to port a server very similar to nginx to snap, is this a wrong use case??

I would consider its requirements “normal” for a server in Linux

write a pid file in /run
write logs in /var/log
write to /var/spool
read a conf file in /etc
write to syslog
I boot master process as root listen to various ports and fork to a new low priv user by name
I need to create a user and group for the worker proceses (is it true there is no snap install script?) what is the workaround?
I need to set process limits (like ulimit)
shared memory access
Consume a lot of RAM potentially
Expose an admin interface on localhost:8181
Install console code and utility scripts.

It seems all of these things are complicated in snap and the tutorials imply none of this is necessary.

Hence thinking maybe snaps are not designed for server applications? I’m pretty confused as to the use case for snaps.

2

I’ll take each of your requirements in turn:

/run is restricted by snapd. To save data you need to write it to $SNAP_DATA or $SNAP_COMMON, although as daemons are handled by systemd you probably don’t need a pidfile.

Again, this location is restricted by snapd. Logging of daemons in the snap world is handled via ssystemd and journald.

This is another location restricted by snapd. You should try to use either $SNAP_DATA or $SNAP_COMMON for this data.

Snapd confinement blocks access to /etc. Your configuration data should be saved in $SNAP_DATA.

Like above for /var/log this is anticipated to be handled by systemd and journald. (Write your daemon’s logging output to STDOUT and STDERR.)

Currently all daemons are run as root, but work is underway to allow snaps to specify dropped-privileges via a user-account: Multiple users and groups in snaps

There is a capability to run a script on initial installation, but this script will be run in the same confinement as your snap will run, and thus cannot alter the system outside of the snap’s restricted execution domain.

I believe you can do this with the process-control interface/plug such as via something akin to the following snapcraft.yaml snippet:

apps:
  my-daemon:
    command: usr/bin/my-daemon
    daemon: simple
    plugs:
      ...
      process-control
      ...

Shared memory is allowed but must conform to a strict naming regime for the device files in /dev/shm. The snap will be unable to access shared memory from other programs that aren’t packaged within the same snap.

Snapd imposes no limits on the amount of memory a snap may utilise.

Once you have applied the network-bind interface/plug then you may listen on any arbitrary port provided, similarly to unconfined applications, that no other program has the same port bound at the time you attempt to open it.

You cannot install these outside of your snap. You can expose commands which point to these codes and scripts, which will be included within the system’s PATH environment variable by default, but cannot apply scripting into the user’s bash profile because snapd confinement prevents access to $HOME without the home plug/interface and even with that interface dotfiles are excluded meaning you cannot modify $HOME/.bashrc or $HOME/.bash_profile.

A lot of effort has been applied to get snaps suitable for both server applications and client applications. In both cases there are restrictions on the manner in which the application can operate when confined, but if you really cannot cope you can still use classic mode, however you may not be able to distribute it via the store: Classic mode requires a manual review by the store admins and may be rejected, unless there is a strong reason for distributing in classic mode.

Ideally all snap packages should have some attempt put into working within the confinement ecosystem as this is the safest for our users.

3

This is good advice in general, but note that there are some /run accesses that are allowed to the snap. Eg:

  • /run/shm/snap.$SNAP.*
  • /run/user/<uid>/snap.$SNAP.*
1 Like
4

Also good advice, but note that some configuration files are readable in the default configuration and depending on the interfaces that are connected.

5

Your snap is free to use ‘logger’ and ‘syslog()’ with the default template.

6

Thanks for the corrections :slight_smile:

7

OK thanks for the response lloks like snaps are not for me.

This breaks the notion of root and paths as UIDs in Linux which is a core paradigm I always code with.

Strange that snaps cant use chroot.

8

Snaps can use chroot. Sorry if this wasn’t clear. Snaps will also be able to privilege dropping-- it is designed and on the roadmap.

I actually think that snaps are a great technology for server applications because you don’t have to worry about all the deep desktop integration bits. You package your applications or application stack in the exact configuration you want, with the exact libraries and dependencies you want and your users will benefit from predictable, reliable upgrades (aka refreshes), rollbacks, security sandboxing, etc without having to worry about your snap breaking the system or other snaps breaking your snap (this is achieved in large part because your snap can only write to snap-specific areas).

From everything in your list (assuming you can modify your snap to use snap-specific file paths rather than writing to /var/log, /var/spool directly; but even this will be made easier with the upcoming ‘layouts’ feature that will let you control the snap’s view of its snap-specific areas (eg, $SNAP_DATA/etc/foo.conf can be accessed via /etc/foo.conf in your snap)), the only thing that isn’t supported today are non-root users and groups, and this is planned. You can choose to use classic or devmode (or strict mode and simply not drop for now) while the feature is being developed.

9

Definitley not prepared to stop using /etc and /var thats silly :slight_smile:

Access to / is really important. All the code I write uses hard coded paths and symlinks for changing the physical location of the file. Paths mean something. This is an integral part of Unix. Breaking that paradigm is not going to work for any of the code I write for Linux. Thats like going back to Windows where file names are meaningless.

This particular code does setuid on workers and this is reasonable, you cant run as root and listen on the network.

There are some people that think security is about bricking up the windows and putting 3 locks on the front door and others that install a burglar alarm and employ a security gaurd who smiles and opens the front door for you when you arrive :slight_smile: