Attempting to snap screen

snapcraft
1

I’d like to have GNU Screen (or tmux, not fussy) on my Ubuntu Core system so I can login once and run a bunch of applications in screens. I tried making a simple snap of GNU Screen using the yaml below. However there’s a few issues with it.

I can’t upload to the store because:

The store was unable to accept this snap.
  - found errors in file output: unusual mode 'rwsr-xr-x' for entry './bin/screen-4.6.2'

If I install the snap I can’t actually run it.

$ snap run screen
Must be connected to a terminal.

I get some apparmor issues.

= AppArmor =                                                                     
Time: Apr  9 13:38:30                                                                                                                                                                                         
Log: apparmor="DENIED" operation="open" profile="snap.screen.screen" name="/etc/shadow" pid=11673 comm="screen" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
File: /etc/shadow (read)                                                                                                                                                                                      
Suggestion:                                                                      
* adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
                                                                                                                                                                                                              
= AppArmor =
Time: Apr  9 13:38:30                                                                                                                                                                                         
Log: apparmor="DENIED" operation="open" profile="snap.screen.screen" name="/var/lib/extrausers/shadow" pid=11673 comm="screen" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
File: /var/lib/extrausers/shadow (read)                                                                                                                                                                       
Suggestions:                                                                                           
* adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON                                                                                           
* add 'account-control' to 'plugs'

It feels like screen would need classic but I want to run it on a core devcie which doesn’t support classic (see also this thread). So do we need a specific profile for these terminal multiplexors?

name: screen
version: '4.6.2'
summary: GNU Screen
description: |
 GNU Screen is a terminal multiplexer that runs several separate "screens"
 on a single physical character-based terminal. Each virtual terminal
 emulates a DEC VT100 plus several ANSI X3.64 and ISO 2022 functions.
 Screen sessions can be detached and resumed later on a different terminal.
 .
 Screen also supports a whole slew of other features, including
 configurable input and output translation, serial port support,
 configurable logging, and multi-user support.

grade: stable
confinement: strict

apps:
  screen:
    command: screen
    plugs:
      - serial-port

parts:
  screen:
    plugin: autotools
    source: http://ftp.gnu.org/gnu/screen/screen-4.6.2.tar.gz
    build-packages:
      - build-essential
      - gcc
      - libncurses5-dev
1 Like
2

I’ve not looked at it extensively, but screen is setgid utmp because it is not built with --enable-utempter. If it was (like tmux is) though, then the snap would end up staging libutempter0, which ships a setgid utmp helper.

I don’t understand why screen needs access to password hashes or expiry data in /etc/shadow. It might be related to its use of pam. It doesn’t seem like tmux needs this access. Have you tried?

Assuming that tmux (you did say you didn’t care which you used) doesn’t need access to /etc/shadow, that leaves how to deal with it shipping a setgid binary. The store has the checks for setuid/setgid as a safeguard to ensure basic DAC checks remain in place with typical usage, so while we could add a per-snap override to allow it, I suspect you are really wanting this to be open to anyone through interface connections, which is incompatible with a snap shipping a setgid binary. I see a few ways forward there:

  • the core snap ships libutemper0 and tmux/screen snaps do not. They use the libutempter0 on the system. We add an interface that allows using the lib and helper
  • the core snap ships tmux itself and we add an interface that allows using it
  • the core snap ships a new ‘classic’ interface (name TBD; Classic interface)
3

Here’s my +1 for shipping tmux in core itself, fwiw :slight_smile:

1 Like
4

Personally I’d also prefer tmux was in the core snap. :slight_smile:

5

In any case, you wouldn’t be able to launch another snap from within the execution context of the current snap, not today at least.

2 Likes
6

At the moment my workaround is to yank the binary of screen from the deb and plop it in ~/bin. On boot I have to mkdir /var/run/screen and chmod 777 /var/run/screen before I can actually run screen. Once I do, I’m all happy with screen running.

Obviously I’d prefer something less janky :slight_smile:

1 Like
7

Any further thoughts on this for the core snap, everybody? I’ve installed core on a pi3, and not having screen or tmux is an ugly experience,

1 Like
8

@mvo - what are your thought on adding tmux to the core snap?