Feature request(reinst + postinst functionality; user account addition)

snapd
7

Not your interpretation, your implementation just happens to be one shunned by the industry for the past 20 years if not longer.

Most (perhaps all) Linux desktop environments allow any user to be designated as an auto-logon user. This can be a non-prived user and, for those (no longer Ubuntu) which supports the concept of a Guest account, the Guest user.

Every major desktop environment allows any user to autostart one or more applications when they log in. Think of Guake if it helps to visualize user level programs which start when the user logs in. Some people even do this with Libre Office modules or Sublime because they spend 90% of their day in them.

Because of these realities, every kiosk type application I’ve ever heard of or worked on (except yours) for the past 20+ years installs a user looking up at Guest for priv and ability. They then install the application as an auto-run under that user and set the user to be the autologon user.

If your kiosk type application gags due to a bug or, more likely, problem with custom video/image/sound/etc. content the user will most likely be dropped to the desktop. In the traditional kiosk world this is a user which can do nothing. Ideally you’ve created that user with a home directory on a RAM drive which gets created and populated at boot so they can do less than nothing. When the Microsoft solution to everything (reboot) is applied, the user has a bouncing new virtual drive with a brand spanking new copy of their world.

The design you propose/champion/have done/whatever, has them dropped to the desktop as a root user.

Not cool.

It doesn’t even have to be a coding bug. Remember, these particular applications are running on full desktop/notebook/2-in-1 computers. What if you just happen to miss disabling one of the or key combinations which will open a terminal? For a user with no more privs than Guest, who cares? It looks bad, but, as they say in hockey “No blood, no foul!”

There is no software developed by an AGILE like process, betting on automated testing, which can or will ever be secure. In general automated tests tend to test less than nothing. Mostly exist to check the box. Snap is also an infant, not yet out of diapers. It’s got an ocean of high priority bugs.

8

thats a (ancient (2014 and later … )) catchall project, actual snap bugs (moved in 16.04 when snaps started to also come over into the normal distro) are under:

9

what facts do you base this on ? no snap desktop application runs as root…

standalone kiosk applications that run confined under a confined compositor are system services though, but there is no unconfined desktop running in that case, nor is there a way for the root owned process to exit its confined environment

it is hard to discuss security if you refuse to even read up about the concept …

1 Like
10

Not even close to hyperbole.

preinst and postinst run ONCE and are generally just scripts, assuming from a trusted source.

The snap environment runs all the time as root. This exponentially increases the odds an untested path has an unitilized pointer or whatever which overwrites your raid controller firmware, blows a hole in the middle of your kernel or some other horrible thing.

That my friend is massive.

Now, if you are talking malicious intent because some fool pulled down a .deb from insert-nationality-here crime syndicate web site, one can do quicker damage, but, even in a snap world they are going to get what they want from you. It’s a case of the immortal words of Ron White, “You can’t fix stupid.”

11

pretty please read the security whitepaper … there is no chance ever that your app can even remotely see your raid controller firmware or any other critical system part …

the whole purpose and design of snaps is exactly crafted around the ability that a developer can do everything, even as root without being able to ever harm the system, this is the only way to allow untrusted sources, which you simply can never allow in a deb/rpm world …

12

pretty please stop jumping to conclusions. I didn’t say it had to be a bug in your app. THE CONFINEMENT itself is still an infant. The package itself has a large number of high priority bugs and there is quite a bit of non-flattering press.

13

this exposes a flaw in X11, not in snap packages, have you read matthews post this senationalist article is based around ?

yes, if you open your snap confinement explicitly by using an insecure interface like x11 (a proper standalone snap kiosk app wouldnt, it would use mir-kiosk which runs fully confined (even for X11 via XWayland)) you indeed inherit the insecurity of what you opened towards…

every x11 app, independently of the package format (deb, rpm, flatpak, appimage, snap) is vulnerable via the described x11 insecurity.

14

There’s a reason the industry doesn’t do it your way. I’m sorry if that offends you, but, there it is.

This discussion has gone completely afield from the original request and is now being abused.

If you don’t have information on the original request, please don’t continue to abuse the thread.

15

Let’s please try to be civil.

@ogra answered that bit earlier, check out snap hooks.

This is indeed not supported, but as you noticed, is something that is still being discussed.

To be absolutely clear: while snap services currently only run as root, as others have pointed out, it is still confined. If the service is exploited to shell access, that shell is still confined.

3 Likes
16

Repeating something doesn’t make it true. An uninitialised pointer in a snap service is not going to overwrite firmware unless it is combined with an exploit which breaks confinement.

Debs from trusted sources have damaged systems. The chrome deb from Google, through those scripts, altered apt/sources.list (and added a root cron job to reapply the change if reverted) in a way which broke the package manager on 64 bit machines. Valve’s Steam deb had a script which ran as the user which accidently deleted the user’s home directory as they forgot to set -e and used an uninitialised variable for a path. So debs from trusted sources can break systems due to the sort of mistakes software developers have always made. Snaps would not have allowed this.

1 Like
17

Maybe.

Assuming none of the bugs in the bug database impact confinement. Assuming that the snap confinement doesn’t have a path through its source which allows for an uninitialized pointer.

Repeating something is confined in a young system with a large bug list does not make it true.

At any rate, without being able to create a real world user and no clear path for multi-arch snaps, this topic is done.

18

this is a new topic you didnt bring up before, what are you missing ? all my non-arch-specific snaps are automatically built for amd64, arm64, armhf, i386, ppc64el, and s390x on the build system …

1 Like
19

With an exception which is fixed recently: More architectures enabled in build.snapcraft.io

20

I think it’s relevant to point out that (again all detailed in-depth in the whitepaper that Oliver provided earlier) that snap confinement is not entirely implemented within snapd, and in fact AIUI all of the security confinement that snapd sets up initially continues to exist and be enforced even if snapd crashes because it uses Linux kernel security modules, specifically:

  • AppArmor
  • BPF style SECCOMP syscall filtering
  • Device control groups (cgroups) in conjunction with udev tagging

(there is also work being done on various other security backends such as polkit and SELinux, all of which AIUI are implemented in the Linux kernel, but I don’t know enough about that work to comment on it any more)

So you don’t need to have absolute faith in snapd’s “confinement” and can instead place faith (and scrutiny) in these security modules that are implemented outside of snapd and the snap ecosystem which run inside the Linux kernel (which is actually where the confinement operates). And as Neil and others have pointed out, the overwhelming majority of deb packages do not use these systems at all, whereas all snap packages are required to use them.

3 Likes
21

I clicked on the link. From what it says this is not a multi-arch solution, but, a multiple package solution, one for each arch.

I did state at some point that this package is one Deb which installs on 12, 14, 16, and soon 18, both 32-bit and 64-bit. The same Deb. It even aliens onto various RPM based distros.

It’s a sneaker-net thing. Machines vary widely but have one thing in common, no network connection of any kind.

22

that means you would need two snaps, one for 32 the other for 64 bit … they will run on ubuntu 14.04, 16.04, 18.04 (not on 12.04 though) as well as on arch, fedora, suse and a few others without specific adjustments.

(do you actually still have users running i386 machines ?)

if your snap does not have any binaries or libs included you can actually build an “architectures: all” snap that runs on all arches.

23

I’m closing this topic. The initial concerns have been addressed, and there’s too much flamebait.

24
25

There is no killer app. There is killer functionality very much needed.

  • preinst + postinst functionality

  • user account addition

For a kiosk like application I’ve been experimenting with migrating a .DEB to one or more snaps. With such an application you need the ability to create a non-priv user then to auto-launch an application for that user. This requires writing to the .config directory of said user, once the install creates the user. Normally, with a .DEB, you do stuff like this in the postinst proc because now you’ve unzipped everything AND you know the architecture.

preinst tends to be used for determining the architecture and which portions of content will be “activated” (for lack of a better term).

The current snap universe seems to be focused on the rather microscopic universe of a single pre-existing user install an app (like a text editor) from a store for themselves or perhaps all users. All of the requests I see for postgresql aliases seems to bear that out.

The ability of snap to completely replace Debian packages in every way, including letting 32-bit executables run on 64-bit hardware is high on the wish list of many.

26

since auto-launched applications always run as root there is no need for users in appliance images at all … (i have built a few appliances on UbuntuCore)

feel free to discuss this in some dedicated new thread though, this one is for “new packaging” suggestions and shouldnt really be abused for random discussions …

1 Like