Idea: Protocol for user accessing system files

Hello community,

this is not really a project yet, just an idea with some thoughts about its implementation.

The typical problem I have in mind is the following: At some point a user tweaks some system settings by editing some configuration files. The tweak works nicely and he forgets what he has done. But then, after some years, something breaks. He goes to the forums, describes the symptoms but nobody can really figure out what is going on. After a lot of troubleshooting it turns out that the change which he made a few years ago and completely forgot about was the reason for the breakage.

Preliminary thoughts on how to deal with such problems: It would be great to have a complete list of system modifications specifically done by the user (as opposed to what is being done during package updates by pacman and is known do the Manjaro devs). This way one could scroll through this protocol and possibly find inspiration when searching for unexplainable problems. Of course it is hard to get a complete list. But I think, a majority of such system modifications can be found by recording any bash command which involves the usage of sudo (people who prefer su are on their own there) and some path outside of /home.

Proposed solution: An alias for sudo which calls sudo the usual way and echoes some information to some plain text journal file: date&time, user who is running sudo, pathes which are present in the command and (just in case) the complete command. Possibly also a diff between old and new version of the file being edited. Details on how to organize the information in a readable way are to be discussed. A GUI with possibility to filter w.r.t. date, path etc would be a plus but considerably more effort.

Questions: Is it a good idea in terms of usability and in terms of security? If so, does something similar exist already?

Thanks for reading,
Photon

Big brother!

I see your point here, but let's think about it again: You can find ALL bash commands you ever entered in your .bash_history file. My proposal just helps to find those of them which might have lead to a breakage.

There are a lot of challenges here:

  • sudo isn't the only way to modify system files
  • Many of the changes people make to break their system are actually in their home folder and not done by root
  • Many of the changes people make to break their system are done through the package manager
  • Determining which files to diff and save would be very difficult as there is often not an obvious correlation between the command run and the files that are modified
  • Going back through this mess would be huge pain

If someone really wanted something like this you could simply use a filesystem that supported snapshots and take regular snapshots. You could then trivially diff different versions of a file, directory or ever a set of directories. This would also allow you to simply rollback if there was an issue.

2 Likes

I agree with @dalto way too hard to implement something like this. Now as for big brother NO, cause something like this would be only viewable on your system NOT sent out to others.

Thanks for your input! :slight_smile:

Sure, but the most common one, I'd assume. The aim is not to provide a complete list which reliably covers all changes to system files, just provide a rather gappy list which still might be some help.

Those are obviously not targeted by the idea. But it is easy to find out that a problem in the home folder is present by testing with a clean new user. Then it is clear that whatever is in the system file modification protocol will not help.

Those are also not targeted by the idea. I'd assume that they are also easier to troubleshoot because they affect more people. Changes done by the user to some system configuration file are, on the other hand, more unique and thus harder to spot.

That's true. Maybe it is good enough to see the command to find the issue so the diffs are not necessary, or at least not first priority.

Better than being completely clueless, isn't it? :slight_smile:

But how would that help if the problems appeared one day ago while its actual cause lies back a few years ago?

In short: I don't propose something which is supposed to be a panacea for all tough to troubleshoot problems but rather something with a very particular scope of application which is described in the initial posting.

conf package modified (only file who can create a .pacnew)

LANG=C pacman -Qii|awk '/^MODIFIED/ {print $2}' | sort

/etc/mkinitcpio.conf
/etc/profile


user adds:

pacman -Qo $(sudo find /etc/ -wholename "*.d/*") 1>/dev/null 2> >(grep -Eo '/etc/.*'  --color=never)

/etc/systemd/journald.conf.d/size.conf
/etc/systemd/journald.conf.d/level.conf
/etc/php/conf.d/php.ini
/etc/sysctl.d/50-coredump.conf


and ? check all packages

LANG=C sudo pacman -Qkk 1>/dev/null 2> >(grep 'Size mismatch')
3 Likes

@Photon, it sounds like you're wanting something like etckeeper.

I was just going to write that one could make oneliner to check which packages have been modified, but you were way ahead of me:slightly_smiling_face:

I use this for make a light backup of my system, packages list and this files in an archive and I've got everything that's interesting

1 Like

I had indeed assumed that the idea was for user who need help to share it on the forum later for troubleshooting.
For personal use, if protected, why not. It seems however only useful for edge cases, for very dedicated troubleshooters (those who prefer to spend hours troubleshooting rather than reinstalling. I have been part of those guys).

What is this reinstalling you speak of.

Aint ever gonna happen. :wink:

2 Likes

What is needed is the ability to keep all config files in a git repo. I try to do this, mostly works.

@photon - what I perceive as the problem is the number of programs that can be used to modify a file - emacs, vim, vi, micro, featherpad, gedit, the list is enormous.

I also keep some files in a local nextcloud instance, but the jury is out on this one :smiley:

2 Likes

Perhaps? But not definitively. There are a lot of ways to get root these days.

That was sort of my point. Why use such a complicated solution that doesn't cover all these cases?

I actually thinks the diffs are far more important. My sudo logs would be pretty useless. You would mostly see me updating the system, installing packages and editing files. Nothing there would tell you what broke something or how to fix it.

I just think there are better ways to solve this problem.

Pull up your snapshot from a few years ago? Presumably you would be using snapshots with different retention periods for different types of data.

This is a great alternative as well. Just write a script on a timer that auto-commits all your changes and optionally pushes them to a remote git repo. I wouldn't want to use that on my music collection but it would work great for /etc, ~/.config and similar.

small test script:

  • find "pacsave" files modified
LANG=C pacman -Qii|awk '/^MODIFIED/ {print $2}'
  • extract originals file from pacman cache
  • run diff /var/cache/pacman/pkg/xxx.pkg.tar.*/xxx.conf /etc/xxx.conf

(writed in go, so compiled) bin and code at :


TODO:

  • exclude some files in filesystem
  • compare local files <-> manjaro gitlab iso profiles

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by