How to track down script or program that messes up permission of folder / ?

[Rava]

Code: Select all

root@rava:/# ls -od /. /..
drwxrwxrwt 90 root 380 2023-09-08 13:51 /.
drwxrwxrwt 90 root 380 2023-09-08 13:51 /..

How do I find out which stupid module script or program messes up my permission of my base folder / (also called the root folder, but not to be confused with folder /root/ )
The settings of / should be like this:

Code: Select all

guest@rava:/mnt/live/memory/images$ ls -od 000-kernel.xzm/.
drwxr-xr-x 5 root 61 2020-04-04 22:28 000-kernel.xzm/.

Or in other (octal) words, it should be 755 instead of 777.

When testing all my modules via ls and grep it seems not to be caused by any of my loaded modules (that was my first guess):

Code: Select all

guest@rava:/mnt/live/memory/images$ ls -od */. /.|grep rwxrwxrw
drwxrwxrwt 90 root 380 2023-09-08 13:51 /.

All base folders of all my modules are like the 000-kernel.xzm one as shown above (=755 as it should be).

I presume, for now the most easy way it to have

Code: Select all

ls -od /.

in my etc/rc.d/rc.local at the very beginning and at its very end; when the permission is already 777 at the beginning of rc.local then it's not made by anything started in rc.local; when it's 755 at the start of rc.local and 777 at the end of rc.local then it must be some script or program started via my own rc.local.
But when its 755 at the start of rc.local and 755 at the end of rc.local … then I have no clue which program causes the issue and how to locate it.

I also would not know out of the box how to locate the script or program that causes the messed up permission when at the beginning of rc.local the setting is already 777.


For now I will put this debugging code at the start of /etc/rc.d/rc.local

Code: Select all

echo 'rc.local ▓▓ start: DEBUG ▓▓ - ls -od /. - ▓▓ continue with Return or Enter ▓▓'
ls -od /.
read

and this at its end:

Code: Select all

echo 'rc.local ▓▓ end: DEBUG ▓▓ - ls -od /. - ▓▓ continue with Return or Enter ▓▓'
ls -od /.
read

Does anyone have additional ideas for tracking down the issue?

[Vic]

Hi Rava.
I know you know about always fresh.

Sometimes I do not notice a problem for months and by then it could be anywhere.

I am not a coder and am overwhelmed by what you and others do in the terminal.

I have 57 modules loaded and rootcopy just for my everyday use. The only way I know how to troubleshoot a problem is to reduce what is loaded by half and see what happens. Rinse and repeat. It is a nuclear bomb approach but I eventually find what I did to cause the problem. I then just nuke the offending module or script and make a new one.

Vic

[Rava]

I have 57 modules loaded and rootcopy just for my everyday use. The only way I know how to troubleshoot a problem is to reduce what is loaded by half and see what happens. Rinse and repeat. It is a nuclear bomb approach but I eventually find what I did to cause the problem. I then just nuke the offending module or script and make a new one.

57 modules. Amazing. I have 19 (with 3 of them being my settings modules alone - one for palemoon, one for my usr_local_bin scripts and programs and one for all of my DE settings) and I thought I have quite a lot of modules at each boot, but you showed me many or few modules loaded at each boot is quite relative.

My initial testing without reboot showed me that it is not a messed up folder from one of my modules as shown with that one-liner

Code: Select all

guest@rava:/mnt/live/memory/images$ ls -od */. /.|grep rwxrwxrw
drwxrwxrwt 90 root 380 2023-09-08 13:51 /.

because then one of my module.xzm/. folders would show up with the grep (just like /. shows up)


If course it could still be one of the modules, when there is some kind of initializing script that does the messing up.

But for now I will follow my approach with the DEBUG in rc.local to see if it turns up some helpful info.

Like I wrote, when the permission is already 777 at the beginning of rc.local or still when it's 755 at the end of rc.local then the issue is less easy to track down.

But I will come to that when I have the info (=after the next reboot). For now I am too lazy to reboot (even when technically speaking the messed up permissions of the / folder is a security vulnerability)


And in case someone might wonder:
I put the pause via "read" in there with good reason. The boot process should be annoying since the debugging info is not meant to be permanent, it should be used to note down the findings and then edit rc.local with either even more debugging output or the knowledge that the thingy that messed up my / was started prior rc.local or was started after rc.local … then I would remove these 6 lines of code and would have to find another way tracking down the issue.

[Rava]

So, I had to reboot due o a different reason and during boot it was how I feared it would turn out:

The beginning of /etc/rc.d/rc.local reported / as

Code: Select all

drwxrwxrwt

and the end also reported it as

Code: Select all

drwxrwxrwt

Since it was not the / folder of one of my loaded modules, it must be some script that runs during module initialization. For now I have to think of what can be done to shrink down where the issue is coming from.
Is there away creating a mini-module that logs its name and status of / onto the harddrive?
Since Porteus only starts the last loaded module's /etc/rc.d/rc.local - how do I do that?

Then I could reduce the scope of where the issue is buried boot by new boot.
Any tips?

Added in 1 day 23 hours 18 minutes 25 seconds:
For now I created two extra rc.* files:

Code: Select all

root@rava:/# ls /etc/rc.d/rc.aaaa_temp /etc/rc.d/rc.zzzz_temp 
/etc/rc.d/rc.aaaa_temp  /etc/rc.d/rc.zzzz_temp
root@rava:/# cat /etc/rc.d/rc.aaaa_temp
#!/bin/sh
echo '/etc/rc.aaaa_temp :
ls -od / :'
ls -od /
echo '▓▓ press Enter / Return to continue ▓▓'

I will report if /etc/rc.aaaa_temp gives me more insight of what's causing the issue. But I have to reboot for that.