Microsoft employee turns smart-alec when systemd wipes part of someones /home folder

yvesjv · 06-22-2024, 04:14 PM

This bug appears to have been fixed in the end but Luca Boccassi of Microsoft just demonstrates why it's not good to let Microsoft take over the *nix world.
That is the same guy that appears to have boasted "42% less Unix philosophy"

https://github.com/systemd/systemd/issues/33349
https://www.theregister.com/2024/06/...data_wipe_fix/

rkelsen · 06-22-2024, 07:33 PM

Yeah. When is the Debian project going to wake up and stop entertaining this excreta tauri?

Mechanikx · 06-22-2024, 09:25 PM

Luca Boccassi definitely puts the "micro" in Microshaft.

This makes me appreciate even more the hardwork that maintainers put in to keep their distribution systemd free.

GazL · 06-23-2024, 06:21 PM

Quote:

Among the issues fixed in version 256.1 are that even as long as five years ago, systemd-tmpfiles had moved on past managing only temporary files – as its name might suggest to the unwary. Now it manages all sorts of files created on the fly … such as things like users' home directories.

Well, that's just stupid.

hazel · 06-24-2024, 12:53 AM

When I was first starting to learn programming, back in the 1990's, a lot was made of choosing sensible default behaviour. You applied the Hippocratic principle: First of all do no harm. Deletion was often cited as the classic potentially harmful action, so nothing should be deleted by default, and even an explicit delete command should affect only what was actually named or flagged.

Mechanikx · 06-24-2024, 08:07 PM

Quote:

Originally Posted by hazel

When I was first starting to learn programming, back in the 1990's, a lot was made of choosing sensible default behaviour. You applied the Hippocratic principle: First of all do no harm. Deletion was often cited as the classic potentially harmful action, so nothing should be deleted by default, and even an explicit delete command should affect only what was actually named or flagged.

Exactly. What if the 'rm' command functioned this way?

No flags? No pathnames? No problem. I'll just delete your home directory.

hazel · 06-25-2024, 12:10 AM

Quote:

Originally Posted by Mechanikx

Exactly. What if the 'rm' command functioned this way?

No flags? No pathnames? No problem. I'll just delete your home directory.

You'll laugh! I actually did that once when I decided to bulk-delete some hidden files by using

Code:

rm .*

I forgot that "." and ".." would be included in that. Fortunately I realised what was happening and pressed ctrl-C before too much of my home directory tree was gone.

Mechanikx · 06-25-2024, 03:24 AM

Quote:

Originally Posted by hazel

You'll laugh! I actually did that once when I decided to bulk-delete some hidden files by using

Code:

rm .*

I forgot that "." and ".." would be included in that. Fortunately I realised what was happening and pressed ctrl-C before too much of my home directory tree was gone.

I've shot myself in the foot with a bulk removal too...once...twice....

There are tools you can use to perform a dry run like ls or find but it would be neat if rm had a dry run option.

Code:

rm --dry-run ...

Then once you're satisfied you could just go up one in your history, and remove that option.

yvesjv · Today, 06:13 PM

And it doesn't get better... saw this on one of the workstations today.
That smartalec has a debian account... best way for M$ to go full EEE is to have a mole onboard.

systemd (256~rc3-3) unstable; urgency=medium

- /tmp/ is now by default a tmpfs, via the tmp.mount unit provided upstream.
The old default setup can be retained simply by masking the unit locally
with (do not do this if you are defining /tmp/ manually in /etc/fstab):

systemctl mask tmp.mount

or:

touch /etc/systemd/system/tmp.mount

It is recommended to check /tmp/ for any leftover files before rebooting
after installing this update and manually cleaning up, as the directory
will longer be cleaned up automatically on boot, as it is overmounted. It
is always possible to remount the root filesystem in a local directory
and remove leftovers manually after rebooting, but this will not be done
automatically to avoid unintential removals. This situation can be easily
detected by checking the journal after a reboot, as there will be a log
message that says:

tmp.mount: Directory /tmp to mount over is not empty, mounting anyway

- /run/lock/ is no longer created with a patch before units start, but by
a standard early-boot run-lock.mount unit that is ordered before
local-fs.target. Any service needing to use /run/lock/ and running before
sysinit.target (ie, they likely define DefaultDependencies=no) will need
to be explicitly ordered with After=run-lock.mount. The two known cases
where this happens in the archive have a bug+MR filed already.

- On new installations, tmpfiles.d will now cleanup by default files
that have not been changed or accessed on /tmp/ for 10 days, and /var/tmp/
for 30 days. The legacy behaviour can be configured with a local override
if needed:

echo 'D /tmp 1777' > /etc/tmpfiles.d/tmp.conf

This override will be automatically provided for upgrades of existing
systems from previous releases to Trixie. As a reminder, individual
files and directories can be marked for exclusion from cleanups with
the 'x' type configuration line as described in the tmpfiles.d manpage,
for example:

echo 'x /tmp/my-precious' > /etc/tmpfiles.d/precious.conf

- coredumps are now disabled by default via configuration files rather than
an out-of-tree patch (installing the optional systemd-coredump package
will enable them as before). As always, overriding via local drop-ins is
possible if desired. The configuration files that respectively affect
the system systemd instance, the user systemd instances and PAM sessions
are:

/usr/lib/systemd/system.conf.d/10-coredump-debian.conf
/usr/lib/systemd/user.conf.d/10-coredump-debian.conf
/usr/lib/sysctl.d/10-coredump-debian.conf
/etc/security/limits.d/10-coredump-debian.conf

-- Luca Boccassi <bluca@debian.org> Tue, 28 May 2024 00:07:57 +0100