Alpine Linux 3.15(alpinelinux.org) |
Alpine Linux 3.15(alpinelinux.org) |
So, that’s why not sudo. As for why doas, see:
>cat /etc/doas.conf
permit persist :wheel
IMHO it really shines on dedicated, small VMs or for headless SBC use cases.
There's only 5 daemons running after the installation (provider in brackets, the installer asks which one for ssh and ntp): - init (OpenRC) - ssh (dropbear or OpenSSH) - ntp (chrony or busybox) - crond (busybox) - syslog (busybox)
The diskless mode it offers is ideal for SBC's or other use cases with SD-cards or such.
So it's niche seems to be with very lightweight or hardened servers.
also, instead of Glibc, it uses musl, which although is supposed to be binary-compatible, does have some gotchas, so the larger the system, with more apps and libraries running on it expecting glibc, will have issues.
My biggest issue was with the 3.12 -> 3.13 transition, when musl got upgraded to 1.2 and with it "musl 1.2 uses new time64-compatible system calls". This broke so many things for me without me knowing, like nginx having as the datetime in the logs the unix epoch. All continued to work, but everything related to timestamps was completely messed up, on 32 bit OS due to running on Raspberry Pis.
This was the moment where I decided to stick to debian-slim, and only very specific containers will continue running on Alpine. Before that it was my default container OS.
Also there is no reliability in packages getting updated, sometimes they just disappear in the next version. But these things are rare occurrences, which only are then nerve wracking when you are confronted with them. For 90% of the cases Alpine is one of the most awesome container OSs.
I don't think there's much credibility to saying it's not "meant to be used" as a desktop; since the packages available suggest to me there's clearly a bunch of people doing just that.
What you can expect is more manual setup (compared to say, OpenBSD, where things work really well out-of-the-box on this hardware). But I took this opportunity to set up an encrypted disk. This is with no "desktop environment", just a window manager and X.
I thought BusyBox would be a pain, but the GNU tools can be automatically installed. Same with musl, which was much less of a big deal than I thought. I can even suggest things feel faster with it, but it does mean staying within packages from the Alpine ecosystem.
I'd be interested if anyone is doing a glibc fork of Alpine (or a way to run the 'full fat' glibc seamlessly, like it does with the GNU tools). Also worth experimenting with Alpine's glibc emulation; I was amazed how good it was, as it runs almost all of a closed-source music production tool that I use.
One thing that surprised me is that KDE's software center gives package update notifications for Alpine packages OOTB, and the GUI Just Works(tm) for installing and upgrading.
? Like most distros that start you off but nothing but a minimal base, you can choose whether to install DBus or not. Almost everyone using Alpine as a daily driver on their PC probably has DBus installed and enabled.
I don't believe it's intended to be used in a desktop environment, but I could be wrong.
apk add python3Alpine is supposed to be a small, stable and secure general purpose base.
Not that doas isn't great, but this particular reason isn't that compelling (to me).
I can agree that process is too complex, but they're not maintaining a fork of vi for that purpose.
Controversial take: i think that it'd be really good to have EVERY configuration file have something like that. For example, if i'm working on a long bit of configuration for fstab, cron, Apache2, Nginx, Tomcat or any other pieces of software, i'd want to see whether everything i've written will be considered valid ahead of time, e.g. a "dry run" of sorts. A bit like we have language servers for VS Code, we could have validation servers as well, for configuration.
That said, i don't think we'll ever have that, since it's easier to just write code in an ad-hoc manner, as opposed to extracting validation of configuration as a separate bit of code that can be called from some CLI, not just at runtime, especially since many configuration files allow nested includes.
Regardless, thinking more about models and validation methods would be nice, e.g. XSD. If we leverage type systems in programming languages, we might as well do that at an operating system level - something like shellcheck built in. A validation handler for every file type.
Here's an example:
$ docker run --rm nginx:1.20.2 nginx -t -g "daemon off;"
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
You can have a custom AuthZ solution and automatically inherit sudo permissions based on groups. It supports a configurable askpass. You can background jobs, change working directory, selectively pass or set environment variables, set $HOME, use a login shell, preserve origin groups, use a chroot, read a password from STDIN, override the shell, set a timeout. And of course the sudoedit features.
I know we all like programs that "do one thing well", but sometimes the best way to support all the use cases we want is a big honking program.
Aside from forcing vim onto innocent users?
> I feel that it's better than `sudo -e`, but would love to see an example where `sudo -e` is better.
It is way worse than `sudo -e`, because it runs the entire editor as root, whereas `sudo -e` runs a few file copies / move as root. So `sudo -e` has a significantly lower amount of stuff in the "secure zone", and thus, much in the same way `doas` is more secure than `sudo`, `sudo -e` is a lot more secure than running the entire editor.
It also works with anything you can set as $EDITOR.
Some editors (like vscode) will outright refuse to run as root by default.
The replies about security are interesting, but I think they are over-complicating this!
Sometimes it's better to power through with a massive labor effort than to try to use fancy hacks to shield people from latent problems. All things considered, it doesn't sound like the Alpine transition was that bad. But it's the type of thing that most Linux users and developers are not accustomed to, at least those who don't remember the very early years. Ironically, musl libc might not exist if glibc hadn't accumulated so much complexity trying to maintain strong ABI compatibility.
IMO, small prices to pay for free software and Free Software.
I build my entire development stack from source and don't rely on OS packages for it, and I absolutely refuse to use binary compiled Python wheels, so Alpine's lack of them is actually a feature as far as I am concerned. I dealt with the musl quirks.
musl wheel support was added some time ago:
https://github.com/pypa/packaging/releases/tag/21.0
No idea how many packages actually build musl wheels though. From a quick glance at least cryptography and lxml has musl wheels.
EDIT: I spoke too soon. Apparently, they have decided to amend the patch in a way that is both backwards-compatible and compatible with musllinux wheels[2]. Hopefully, it will roll out soon.
[1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13227 [2]: https://bugs.python.org/msg406939
https://github.com/insightfulsystems/alpine-python/blob/5a34...
But I haven’t tested today’s version yet.
You just need to know how :)
Regarding the "runs just fine", this is not guaranteed. I certainly do check if it is working, and if it is, and it is a small service or just a containerized tool, then I'll use it. Like using GDAL to perform some reprojections and renderings where a throwaway container is called from a shell script, if it works once, I'll keep using it, but I won't use it to run a Python server which also makes use of Matplotlib and other big dependencies.
The entire point of sudoedit is to reduce the attack surface, without that it's absolutely useless since you can just `sudo` whatever editor you prefer.
> Aside from forcing vim onto innocent users?
> `sudo -e` runs a few file copies / move as root.
No, it does not. It runs whatever EDITOR is set to (technically the first set of SUDO_EDITOR, VISUAL, and EDITOR).
> So presumably that means that it will have my environment, e.g. will run my .vimrc?
That is correct.
> Though that could be an attack vector too.
Only on the specific file, which would usually be a lot more noticeable unless the attack specifically manages to recognise and target sudoedited files while closing the buffer.
> Only on the specific file, which would usually be a lot more
> noticeable unless the attack specifically manages to recognise
> and target sudoedited files while closing the buffer.