Policy rule how-to for preventing live user to erase things

[voxel]

Hello folks ^^)

I have a problem with a customer that regularily kill his Mageia by erasing all sys prefs (everything) located in /home in the .something folders, then calls me to say that his system does not work as expected...

and as he's emptying the trashcan each time, nothing can be salvaged even with good data retrievers.

don't know if it's alzheimer or else but all that I've done yet to prevent that has been circumvented by that customer and he seems to not remember what I say to him about not touching anything there that he hasn't copied himself and let the system live alone...

How can I create a policy rule that strictly prevent someone not root to erase anything that it should never put his hands on ?

Help ! please ^^)

Jeff

[doktor5000]

What do you mean with "live" user in the subject, can you provide some more context information on that?

You could change the owner to e.g. root and add the sticky bit to some files, to prevent the user from deleting them. See e.g. https://unix.stackexchange.com/a/20106/83329
Other basic options are to make all the existent files immutable, which will also create issues of its own as he cannot change any options and it might also cause some programs to crash. AND those files would still be deletable, even if you get a message saying that it's readonly.

You could mount the /home filesystem readonly, or only a part of it as a bind mount, but then you would have the same issues as above and he would not be able to create any files.
Or you could make his /home as an overlay filesystem, similar to how persistence is implemented: https://wiki.mageia.org/en/Installation ... ry_devices

You could also tell the customer that he broke it, and pay you for repairing it. That's on you, though.

[voxel]

What do you mean with "live" user in the subject, can you provide some more context information on that?

I mean the guy between the keyboard and the chair as the 'live' user

You could change the owner to e.g. root and add the sticky bit to some files, to prevent the user from deleting them. See e.g. https://unix.stackexchange.com/a/20106/83329
Other basic options are to make all the existent files immutable, which will also create issues of its own as he cannot change any options and it might also cause some programs to crash. AND those files would still be deletable, even if you get a message saying that it's readonly.

You could mount the /home filesystem readonly, or only a part of it as a bind mount, but then you would have the same issues as above and he would not be able to create any files.
Or you could make his /home as an overlay filesystem, similar to how persistence is implemented: https://wiki.mageia.org/en/Installation ... ry_devices

couldn't do that as all the software (firefox, thunderbird, system components (kde, etc) will be unable to save their preferences there, remember that we speak of the hidden .(something) directories saved in /home

You could also tell the customer that he broke it, and pay you for repairing it. That's on you, though.

already done lotsa time but he forgot and do the same error again and again.

I'm pretty sure that we can do that protection with a policy rule, permitting all software running under user ID to save their prefs and preventing any manual erase of it by the customer, but I don't know policy enough and how to implement it. (never had to touch anything there yet and don't want to break something...)
hence the help question ^^)

[doktor5000]

Policy for what piece of software that should implement that policy?

As mentioned, changing the owner of those files to root and adding the sticky bit would exactly allow what you're asking for. If this is a sane thing to do is another question ...

[jiml8]

Presuming that for some reason you cannot just ditch this client, there are a few things you can do.

I would consider deploying an overlay filesystem, then on boot do a chroot into that overlay for his graphical user session. This would have the effect of making his changes non-persistent. If he needs some persistence for some things, you could handle this by setting up a different partition that does not participate in the overlay.

You also could set up a cron that would use rsync to backup the critical config files that he keeps deleting. Then you could just restore them, or configure an auto-restore.

Again presuming that for some reason you really have to deal with this client, probably some combination of the two ideas will get you to where you need to be, with him having a system he can use but not easily destroy..

[JoesCat]

In terms of everywhere outside of /home/user
You may also want to add your own custom msec file since msec is usually running, and you don't want msec to undo any settings you have already set.
I wouldn't recommend setting secure or paranoid modes, as that can bring a whole bunch of extras that might not work well with the live user, but what you can do is substitute your own custom file that is something better than perm.standard but not necessarily as strict as perm.secure

[voxel]

Presuming that for some reason you cannot just ditch this client, there are a few things you can do.

he's a relative, but getting old...

I would consider deploying an overlay filesystem, then on boot do a chroot into that overlay for his graphical user session. This would have the effect of making his changes non-persistent.

good idea I've never done that, can you tell me more on how to do that ?

If he needs some persistence for some things, you could handle this by setting up a different partition that does not participate in the overlay.

there are all the setttings saved in .dirs in /home by all software and system components that must be preserved, I presume it's that stuff that'll goes into there, (what he do with his own created files isn't important). btw, how to tell the softs that it must use there to save their settings and not in their default /home/.dirs ?

thinking of it, is there something that can restrict the showing of hidden directories to the Root and deactivate/refuse it when called by the user ??? (at least if he can't see that .dirs, he wouldn't want to erase it...)

[JoesCat]

example:
drwx------ user.user .kde4/
drwxr-xr-x user.user .local/
drwx------ user.user .thunderbird/

try:
drwx-----x root.guardian .kde4/
drwxr-x--x root.guardian .local/
drwx-----x root.guardian .thunderbird/

[jiml8]

I would consider deploying an overlay filesystem, then on boot do a chroot into that overlay for his graphical user session. This would have the effect of making his changes non-persistent.

good idea I've never done that, can you tell me more on how to do that ?

Well, there is a fair amount to it. Begin by studying how to use the overlay filesystem. You can start here: https://wiki.archlinux.org/title/Overlay_filesystem

Likely you would want to overlay the entire / system for this overlay.

After you have set up an overlay filesystem, you will want to do a mount bind on the various pseudo directories (/dev, /sys, /proc) so that entries there would be available in the overlay.

An example mount bind command would be:

Code: Select all

mount -o bind /dev /myroot/dev

where /myroot is the root of the overlay filesystem that you set up

After you have everything set up, then your session would issue the command:

Code: Select all

chroot /myroot

Once you have done this, you can start the user's graphical desktop in that session, and it will come up using the overlay, and any consoles started in the desktop will also use the overlay. All of the user's changes will be non-persistent.

Note that you have to alter the machine's startup to do this. Offhand I don't know where the best place to make the change would be; someone else might chime in with a recommendation. The real issue here is that systemd is parallel in its operation, and you want to change only the user session, not the entire system. So likely you want to hook the user startup where the desktop is loaded. I am sure it will require modifying system scripts.

Having done this, you then will want to make some of the stuff he does persistent - notably the config files you are worried about. I would handle this using a script in either bash or python that runs outside the user context (in other words, you start it earlier in the bootup process, and it is not part of the user context that is in the chroot), and that script would compare the copy of the config file that is in the overlay (for instance, /myroot/home/blah/.local/thisconfig) to the one on the underlying file system (/home/blah/.local/thisconfig) and would update the underlying file to match the overlay file (except, of course, you wouldn't delete the underlying file if he deleted it). Any of his own stuff that was to be persistent could be handled with a separate partition that does not participate in the overlay system.

As you can see, setting this up would cause you to spend a lot of time. It would, though, completely solve your problem. Is it worth doing? Well, I don't know. Only you can answer that one.

[JoesCat]

Note that you have to alter the machine's startup to do this.

I think the best time to do this is before the user logs in.
If you have your own script to do something like this - http://www.joescat.com/boinc/#GETD - then it pretty much runs right from when the computer starts up. Note: any script you write to run through init.d, needs to be compatible with "sh", not "bash". If you read through the whole page, it hopefully gives you enough info so you can setup your scripts the way you need for your task. Done correctly, it even shows-up in the Mageia services and daemons menu list where you can toggle start/stop, on boot using the gui

[jiml8]

I just edited my second post on this thread to fix a couple of typos that affected the accuracy of what I wrote, particularly my example mount bind command, and an inconsistent use of "myroot" vs "mydev".