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

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.

It wasn’t abuse or a random discussion. The title of the other thread was

Snap wishlist - suggestions wanted!

and it made no restriction/limitation of the wishlist being only for new packages. The above requested features, especially the ability to create users.

At any rate, your assertion that auto-launched applications always run as root is completely incorrect. On some single application embedded systems poor design would have the application running as root, but, most, especially in the FDA regulated medical device world (been there, done that, got the t-shirt), run as a user with minimal required privs. The reason behind such a regulation is the kernel can protect (in many cases) a mere mortal user from programmer stupidity/unintialized something or other. It will kill the offending application off and the (usually hardware) watchdog will re-launch it. Some watchdogs will even trigger the transmission of the last N-thousand bytes of syslog along with configuration information so a failure can be analyzed.

Even industrial devices with custom Linux builds will avoid running as root for the very same reason. Got both the t-shirt and hat.

Having said that, there are literally millions of kiosk style applications running every day on ordinary desktops, laptops, tablets and other consumer devices. These applications all install as a captive/non-prived user and can be removed by nuking the kiosk user from a root/admin account. Applications like these are everywhere and none of them run as root. You will see them at trade shows/fairs, seminars and pretty much every big box store in the world. (Walk through the computer section and see if you don’t find quite a few (all?) with some kind of “Explore this computer” kiosk application.) When the promotion ends, or the store needs to sell the “open box” item, they nuke the kiosk user and the machine is now ready either for the current owner to continue using it or for the purchaser to perform their very first login and set up the machine.

Sorry, but I’ve been at this software development thing a while.

Not trying to be a jerk or anything, just pointing out the width of experience in one’s past dramatically impacts the width of one’s field of forward vision.

If snap really wants to earn the slogan of “universal Linux package” or whatever, it must provide all things Debian and RPM provide. Keeping tunnel vision focused on single person apps downloaded from some store and installed by an ordinary user won’t let it achieve that status.

well, the initial post of that topic is pretty clear that the thread is looking for new apps to package suggestions … and i personally felt clearly like i’m abusing our longest running package suggestions topic with keeping the discussion there …

note that this is mainly about creating users inside the snap runtime environment (for apps that today require patching because they insist on privilege dropping) … if you want to create an appliance image and add a user today on an Ubuntu Core system, you need to use a system-user assertion or have a brandstore which allows you to have a snap with the snapd-control interface enabled in there, so you can call “snap create user” from this snap …

have you taken a look at install/remove hooks (and there are plenty of other hooks) ?

Well, this is the status quo for snaps … i didnt make an assertion here but stated a fact. snaps that run in a kiosk environment on UbuntuCore always run as root today (snaps that run as system services on a classic install also always run as root; there is no user-session auto-start feature today) and you would typically not even have a user on the system (yet, indeed you could be using the system-user assertion or the interactive console-conf) unless you are doing development …

note that snaps can not see anything more from the system or execute any out-of-snap binaries than the interaces allow that you picked for your snap (any security-critical ones will not auto-connect without a user or a gadget snap (in case of an appliance) explicitly requesting it), the confinement is designed especially with running as root in mind.

i’m actually not really after a debate on principle, though …

you sounded like you are after help to get some kiosk setup done and i have experience with it and would be happy to help if you could give some more details about what show stoppers you have hit, Ubuntu Core and snaps are simply designed different from how things have been in the deb and rpm world. I’m happy to help you finding the right ropes if needed …

EDIT: i just noticed that you picked the snapcraft category for this post, if you want to have a feature discussion i’d suggest picking the snapd category (which will be watched by the right team) since that is where package features get implemented and managed, snapcraft is the tool used to create the packages, but it only follows snapd if it comes to snap features

The bulk of what I read had to do with creating users in the real world, not inside. Is someone seriously considering one snap with Postgresql in it, a database which must be actively managed, making it unreachable for other snaps? Never mind, don’t answer. That’s a catastrophic architecture discussion which I do not wish to have. Bad design decisions run unrestrained.

Most importantly, this is not an appliance. Ubuntu Core has no place in the conversation. None what-so-ever. This is a single task user which gets added to any Debian or RPM based desktop. It is NOT an appliance.

My previous description was and is as detailed an accurate as I’m allowed to be. The only reason I’m looking at snap packaging is for ease of library bundling. Currently this is a multi-arch Deb/RPM compiled on 32-bit platform bundled with everything it needs for raw install on a fresh from ISO DVD of whatever distro. Everything exists and has existed for a good number of years.

If snaps run as root this is massively insecure, but, I find it difficult to believe someone who installs notepadqq from a snap has it running as root.

I’ve not used Ubuntu Core, mostly Yocto builds. I have lots of stuff running vending machine touchscreens on Raspberry Pi cards, none of it runs as root. Running anything as root is just failed design.

If I have time I will move the discussion yet again, but, so far, from what I’ve heard, snap will be too insecure to consider. It is just too architecturally unsound. The first uninitialized pointer could blast RAID firmware or anything else.

With all appropriate respect, some of that is hyperbole. Nothing in the snap ecosystem is as big a security hole as the pre and post install scripts in deb packages, which run as root, are unconfined and can do anything they like to a running system. Running as root within snap confinement is much safer than running as root outside confinement. I agree there’s a debate to be had as to whether that is more or less dangerous than running as an unprivileged user outside confinement. However, the model looks sound to me.

1 Like

Also, although services will run as root, a strictly confined user app will run as the user who invokes it (with the additional restrictions of the confinement).

then i’m sorry for misunderstanding you …

notepadqq is not a service buit an enduser app … so indeed it runs as the user that started it in her dektop session…

snaps you auto-start today have to be systemd services though and these have to run as root … perhaps my interpretation of the word kiosk is wrong but to me it implies that the application is a standalone thing starting full-screen with the system when you boot up …

did you read up about snap confinement yet ?
the security model of snap packages is outlined in detail on page 20-27 (ignore the fact that it says UbuntuCore all over the place, all these bits apply in general to snap packags) here:

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.

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:

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

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

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 …

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.

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.

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.

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.


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


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.

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

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

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.