Tobias Hunger

Those evil companies block random users, just because their government made some laws about it.

Usig anything as root is a security risk.

Using any UI application as root is a bigger risk. That’s because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.

So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.

Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.

Ideally you run the UI as a normal user and then use sudo to run individual commands as root.

I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.

Oh, most companies will pay someone to maintain an internal fork, but hardly any will contribute back. Sometimes that’s due to lazyness, sometimes it is the idea that nobody will care for the company internal stuff, but most of the time it is outright forbidden to share internal IP even when that comes in the form of patches to open source code.

In my experience it is safe to just ignore that case and not care about corporate convenience when starting any open source project.

Most of your examples are projects started by a company. The very few remaining are those 0.01% that got lucky.

My point stands: When you start an open source project, there is no need to worry about what companies might like or not. You will not get money from anyone.

You make it sound as if corporations actually contribute a lot to open source projects they use. That is not the case in 99.9% of all cases where corporations decide to use some open source project.

If you are lucky as an open source maintainer you get a few patches from devs using their private email addresses to sneak the contribution around the legal department, but even that is rare. What you will see is random requests from company users to provide an SBOM for the entire project right now or bug reports asking to fix something right now.

So I seriously doubt you loose out when using AGPL or GPL.

The one thing you can learn from sysv init isnthat asking devs to pitncode into their programs or into starter scripts does not work. They will not bother: Those will notmworkmcross platform.

So you need to cebtralize that task. You can either write a wrapper program that sandboxes starts applications in a sandbox or do that whereever the programs as are started anyway.

A separate sandboxing app that starts services complicates configuration: You basically need to configure two things the starter and the service. On the up-side you have the sandboxing code separate. Merging the sandboxing into the program starting the service makes configuration simple but adds moremcode into the the starter program.

So it is basically a decision on what you value more. Systemd decided to favor simpler configuration. The cost for adding the sandboxing is small anyway: It’s all Linux kernel functionality that does need a bit of configuration to get rolling, with much of that code being in the systemd-init anyway: It uses similar functionality to actually separate the processes it starts from each other to avoid getting confused by programs restarted and thusnchanging PIDs – something still a thing in many other inits.

I am convinced that making sandboxing easy does a lot formits adoption. No admin will change the entire startup configuration to add a sandboxing wrapper around the actual service. It is way more likely for them to drop in a override file with a couple of lines and without any problems when upstream changes command line options.

To be fair: snaps can work for all kinds of things all over the stack from the kernel to individual applications, while flatpak just does applications. Canonical is building a lot around those abilities to handle lower level things, so I guess it makes sense for them.

IMHO flatpak does the applications better and more reliably and those are what I personally care for, so I personally stay away from snaps.

It is the same as with all logins: It goes through the Pluggable Authentication Modules. So you need a service that uses PAM (they basically all do for a long time now) and the configuration of that service needs to include homed as an option to authenticate users. Check /etc/pam.d for the config files.

I use toolbox: Distrobox is a pretty horrible shell script and deleted parts of my home directory when I tried that.

In the end I just pointed toolbox to a script named podman that just adjusts the setup to what I need, implementing the missing features I wanted that way.

Censorship is about you being limited in the actions you can take to express yourself. It is not about cushioning you from the consequences of those actions from the people around you.

You obviously were allowed to take action: The contents was apparent upon on a forum and here as well. People reacted to your actions: Admins removed your contents and blocked you and I am telling you that your understanding of wayland as well as politics is limited.

Deal with it.

Small communities have a hard time staying up to date. X11 was ported decades ago, when non Linux OSes had more mind share and commercial backing. I doubt anyone could port X11 if that was the new thing mainly developed on Linux today.

Yes, wayland by design does not let random applications grab events intended for other applications nor does it let random applications take screenshots at any point in time showing other applications screens. This requires applications to do screen sharing differently, and it indeed breaks random applications sending events to random other applications. That is basically all you wail about and an absolutely necessary property of any sensible system and it is very embarrassing that it took so long to get this.

Removing dump stuff to keep a community relevant, on topic and with a good signal to noise ratio is not censorship. Claiming so is just dumb.

One more reason to run the steam flatpak: At least I can sandbox away things steam does not need to concern itself with.

The point of using the TPM is that it does not unlock the drive unless it has a certain set of software is loaded in a certain sequence on the machine with that specific TPM chip.

So if somebody breaks grub and makes it load a shell, then that results in different software loaded (or at least loaded in a different sequence) and will prevent the TPM to unlock the system. The same is true if somebody boots from a rescue disk (different software loaded) or when you try to unlock the disk in an unexpected phase of the boot process (same software but different sequence of things loaded, e.g. after boot up to send the key to some server on thr network. The key is locked to one TPM, so removing the drive and booting it in a different machine also does not work.

The TPM-locked disk is pretty secure, even more so than that USB idea of yours – if the system you boot into is secure. It basically stops any attacker from bringing extra tools to help them in their attack. All they have available is what your system has installed. Do not use auto-login or run some root shell in some console somewhere…

But if the key is fully wrench-safe inside the TPM. You do not know it, you can not get convinced to give it up – even after repeated wrench use.

Of course the recovery key that typically goes with it and you logging password is not wrench safe, so that does not protect the system fully, while getting you a matching set of broken kneecaps.

The idea behind TPM-locked boot is that you can boot into your system unattended, but it stops booting into any other system. Typically no password is needed, but you can also assign an additional (non-user) password if you want.

This is nice if you trust your system to be basically secure. Nothing else can access its filesystems, so no external tool can be used to break into it. Rescue disks can not access any data without knowing a special rescue key – so make sure to set one up! A nice side effiect is that the key is only available while setting up disks in the initrd and totally inaccessible at any other time. That makes it very hard to extract the password once the system is running.

You can encrypt the home directories of users using other services like systemd-homed. That will prevent anyone from accessing any data in the user’s directory while that user is logged out. Homed will basically use your password to unlock your disk and if that works, then the password is accepted. So you do not need that user to be listed in the traditional /etc/passwd file, which is useful as you can just copy the users homedir image file onto another system to move a user account over.

Add a /var partition, boot from some live system, copy over the data, delete it in the root partition after making sure it was copied ok and add the new filesystem to fstab. /var is the only place we that will grow significantly(especially when younuse flatpaks).

Last time I tried it was an apt install followed by a reboot. If your distribution claims to support several inits and it is harder than that: Your distribution did a poor job.

Where are those “many of us”?

It is what the CI uses for testing. If several layers of people decide to not do their job and you have no hardware in your network that announces the DNS servers to use like basically everybody has, then those CI settings might leak through to the occassional user. Even then, at least there is network: Somebody that can’t be arsed to configure their network or pick any semi-private distribution will probably prefer that.

Absolutely no issue here, nothing to see.