strange file permissions in system directories

[kmathern]

@kmathern I think you meant @Adrian

Thanks, I did.

[j2mcgreg]

Is this on hard metal or in a live session?

Hmm, the OP says it's a boot from ISO, and the username is "demo", so it's very unlikely it's something else than a live session. A live session, in turn, can run on hard metal or in a virtual machine.

His QSI says that he is running Virtual Box, so assuming he is using a live system there it must be something or lacking in VB that is messing with permissions and ownership. His problem wasn't duplicated after a clean install on my HP 17 test laptop.

[Nokkaelaein]

it must be something or lacking in VB that is messing with permissions and ownership.

I find that extremely unlikely. A virtualization solution causing file permissions and ownership to change is a much bolder proposition than checking whether the software being run is doing it for some reason by itself.

Also, the idea in my comment was, running on "hard metal" vs. running a "live session" are not mutually exclusive comparative scenarios.

If a system installed on a test laptop doesn't exhibit this, then instead of jumping to the conclusion it must be Virtualbox messing with file permissions and ownership, the more appropriate distinction to test next is whether there is a difference between an installed system and a live system. So, check whether the test laptop shows this behavior when you test in a session that has been booted live from USB, not installed.

[BV206]

Is this on hard metal or in a live session?

It happens in VirtualBox when booting the ISO file. I don't have a MX VB installation right now.
It happens when booting the ISO from USB drive on a real PC.
It happens on a persistent live USB on a real PC.
It happens on my main daily driver MX installation on a real PC.

The sysctl config file permissions are also executable everwhere.
I haven't changed those and I don't think any tools or settings ever change those.

[CharlesV]

I can also duplicate the repo issue on both a clean machine and my main rig ( Both hardware loads) - as kmathern pointed out, changing something on the Individual Sources tab appears to cause this.

[BV206]

Also there is a another thread about the Live USB Kernel Updater not working. It's .desktop file has the wrong path to the executable file in all my cases.

[dolphin_oracle]

Also there is a another thread about the Live USB Kernel Updater not working. It's .desktop file has the wrong path to the executable file in all my cases.

yep, missed that when we moved it out of /usr/local/bin. update on the way.

[dolphin_oracle]

The sysctl configuration files that MX adds for swappiness and dirty bytes in /etc/sysctl.d are executable for some reason.

Code: Select all

$ ls -lah /etc/sysctl.d
total 2.0K
drwxr-xr-x 2 root root 119 Jun 15 18:49 .
drwxr-xr-x 1 root root 500 Aug 16 11:40 ..
-rwxr-xr-x 1 root root  19 Feb  8  2025 99-swappiness_mx.conf
lrwxrwxrwx 1 root root  14 Mar 11  2023 99-sysctl.conf -> ../sysctl.conf
-rwxr-xr-x 1 root root  26 Feb  8  2025 99-vm-dirtybytes_mx.conf
-rw-r--r-- 1 root root 798 Dec 19  2022 README.sysct

Are these intentional? mistakes? bugs? security vulnerabilities?
I'm just a dumb user. I don't think somebody like me should be finding stuff like this.

thanks those executable bits will be fixed in the next update of mx-system.

[Adrian]

Sorry about this, I fix the ownership and permission when I do the other changes but I forgot to add for when editing the file, fix should come shortly though the repo.