Check and manage pacnew files

Hello,
I noticed that many people don’t know about pacnew files or at least don’t pay attention to their creation during the upgrade phase. To help even those who don’t pay attention, I created a bash script with yad GUI that simulates pacdiff actions.

The program runs in the background and opens when new pacdiff files are found. Maybe it won’t be the best approach but if anyone has other ideas they are welcome.

for contributions

https://packages.manjaro.org/?query=manjaro-pacnew-checker

Enjoy and regards

Stefano

14 Likes

I would’ve suggested adding it to a pacman hook…

I can’t… this is already suggested by @Yochanan in our private chat but for security reason, i can’t open a GUI during the upgrade via pacman hooks because it is open at the root level. This script runs in background and checks any 10’ . This is only a starter, we can always do better.

Makes kind of sense yes. Although I’m sure there is a way…let me think…

Edit:

I’m guessing it won’t work to run it with sudo -u?

$ manly sudo -u

sudo, sudoedit — execute a command as another user
==================================================

-u user, --user=user
Run the command as a user other than the  default  target  user
(usually  root).   The  user may be either a user name or a nu‐
meric user-ID (UID) prefixed with the ‘#’ character (e.g., ‘#0’
for UID 0).  When running commands as a UID,  many  shells  re‐
quire that the ‘#’ be escaped with a backslash (‘\’).  Some se‐
curity  policies may restrict UIDs to those listed in the pass‐
word database.  The sudoers policy allows UIDs that are not  in
the  password  database  as  long as the targetpw option is not
set.  Other security policies may not support this.

I know the -u switch but for pass the password i need to open a CLI. I use pkexec instead

There is definitely the need of it for new users, that only click on “apply” in pamac and don’t read the log. We have the Manjaro Notifier to notify for unsupported kernels, pacnews are just as important as we saw with the removal of the extra repo. So for me this actually belong there in the long run. On the short term i think this should be shipped and enabled by default on new installs. Even if it is only in english for now.

We actually discussed it recently here

Congratulations for the script, if looks very nice. My 2-3 cents @Ste74 when i look at the source:

  • isn’t 10 minutes a bit too frequently and waste of CPU? At least make it an hour or so?
  • meld and yad are not installed by default, i hope you marked them as dependencies (cannot check my mirrors seem not to be updated yet)
  • you have a tiny spelling error #Cicla / #Circle
3 Likes

Great work!

From the screenshot I already have a few suggestion if you don’t mind.

You probably should add safeguards for some of the configuration files, I’m thinking about the /etc/shadow config file or some similar critical system files that should not be overwritten without knowing the consequences.
Maybe add a group of hard-coded files, some sort of list that could be expanded in the future, that will not be treated the same way, so it is safer for the normal user who usually click “next next next” (maybe remove or change options available).

The “conflict” term is a bit strong to my taste but I guess this is a whole discussion for a point of detail in the end.

3 Likes

So the idea is this should be running always and relies on that sleep loop?
Why not use systemd+timer ?

Also … why does it specifically ignore pacsaves? They can be important too.

More typos also:

# The user has chosen to opening the diff files.

(better would be “The user has chosen to open the diff files”
except … they arent diff files … so its somewhat misleading.
A bit like the next text issue:

Management of configuration conflicts completed.

There arent really conflicts.

Oh, and, it should be mentioned that the admin:* bit you are using in meld is a function of gvfs … so that would need to be a depend too.
( I would know … because this approach is directly lifted from my fork I shared here :wink: )

1 Like

Thank you, yep i need to increase the time and my english is not my best…

1 Like

Was my first attempt but yad can be called from a systemd service? Is an admin ( root ) service right ?
Right pacsave can be managed also… and yes my english is bad :zipper_mouth_face:

First - systemd user units exist … and second - theres nothing saying you cant use sudo -U
(remember sudo is not equivalent to “super user do” it is more equivalent to “do as” … and that can be any user)

EDIT

And heres some more food for thought.
Sorry for the tome … it looks bigger than it is because of quotations. :sweat_smile:

I should clarify again that pacdiff -s accomplishes this already quite well, which is why I eventually considered the fork unnecessary.

While somewhat less than intuitive … the ‘view’ option of pacdiff indeed works as ‘view and edit’, while -s is not simply ‘pass sudo’ … its rather sudoedit … meaning it handles permissions properly and is acting on temporary files and uses sudo afterwards to apply changes.

man pacdiff
[...]
       -s, --sudo
           Use sudo and sudoedit to merge/remove files.
[...]
[...]
       -e, --edit
               Edit  one  or more files instead of running a command.  In lieu of a path name, the string "sudoedit" is used when consulting the security policy.  If the user is autho‐
               rized by the policy, the following steps are taken:

               1.   Temporary copies are made of the files to be edited with the owner set to the invoking user.

               2.   The editor specified by the policy is run to edit the temporary files.  The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment  variables  (in  that
                    order).  If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.

               3.   If they have been modified, the temporary files are copied back to their original location and the temporary versions are removed.

               To help prevent the editing of unauthorized files, the following restrictions are enforced unless explicitly allowed by the security policy:

                •  Symbolic links may not be edited (version 1.8.15 and higher).

                •  Symbolic  links  along the path to be edited are not followed when the parent directory is writable by the invoking user unless that user is root (version 1.8.16 and
                   higher).

                •  Files located in a directory that is writable by the invoking user may not be edited unless that user is root (version 1.8.16 and higher).

               Users are never allowed to edit device special files.

               If the specified file does not exist, it will be created.  Unlike most commands run by sudo, the editor is run with the invoking user's environment unmodified.   If  the
               temporary  file becomes empty after editing, the user will be prompted before it is installed.  If, for some reason, sudo is unable to update a file with its edited ver‐
               sion, the user will receive a warning and the edited copy will remain in a temporary file.
[...]

…meaning … that there is not a reason to make all of these extra functions.
If you need/want to add yad or other graphical notifications and/or buttons then go for it.
But pacdiff -s alone will handle all of the pacnew/pacsave and permissions and editing and so on … so long as DIFFPROG is set to whatever your preferred editor is. If set to meld … then pacdiff -s will do what this utility does, but better (just without the graphical prompts) … so I humbly suggest you revisit this with these things in mind …
Once again:
yad = ok
circumventing pacdiff for no good reason = less ok

1 Like

:joy: Use AI to dumb it down even more. The future.

I try to run this function after a big update, and handle the pacnew files then.
But at the moment, I don’t understand how to exclude path’s out of a find command.

pacnew() {

    sudo find / -iname '*.pacnew' -type f -print -not -path '/run/*'

    # todo try to exclude path's
    # sudo find / -iname '*.pacnew' -type f -not -path '/proc/*' -not -path '/run/*' -not -path '/timeshift/*' -not -path '/var/log/*' -not -path '.config/VSCodium/' -not -path '/timeshift/*' -print
}
find / -type f -name "*.pacnew" ! -path "/proc/*" ! -path "/run/*" 2>/dev/null

(I cant seem to force find to not look at /run/user/1000/ either)

Ah here we go:

sudo find / \( -path /proc -o -path /run -o -path /tmp \) -prune -o -type f -regex ".*\.pac\(new\|save\|orig\)" -print

and a bit smaller with regex:

sudo find / -regex /"\(proc\|tmp\|run\)" -prune -o -type f -regex ".*\.pac\(new\|save\|orig\)" -print

(added pacsave and pacorig too)

yes. its the tool for the job, but for some reason people avoid it.

1 Like

If you just want to list them wouldn’t pacdiff -o be a lot easier?

1 Like

That’s what Stefano is using. The find function question seems to be another project.

Sure, it would still just be great to know a universal method where I can use on different stuff aswell.

If you’re using pacdiff, then you’ve also got paclog installed too:

paclog --after=2023-07-01|paclog --warnings
[2023-07-29T02:20:59-0400] [ALPM] warning: directory permissions differ on /etc/credstore/
filesystem: 0  package: 700
[2023-07-29T02:20:59-0400] [ALPM] warning: directory permissions differ on /etc/credstore.encrypted/
filesystem: 0  package: 700
[2023-08-07T11:42:19-0400] [ALPM-SCRIPTLET] error: No package owns /usr/lib/perl5/5.36
[2023-08-08T22:40:27-0400] [ALPM] warning: directory permissions differ on /boot/
filesystem: 700  package: 755
[2023-08-11T12:14:07-0400] [ALPM] warning: /etc/ssh/sshd_config installed as /etc/ssh/sshd_config.pacnew
[2023-08-23T20:10:05-0400] [ALPM] warning: /etc/pacman.d/mirrorlist installed as /etc/pacman.d/mirrorlist.pacnew

:man_shrugging:

1 Like

Well manjaro-pacnew-checker now is at 0.2.0 version and i have correct my bad english, pacnew and pacsave are listed and i switched to a systemd service. Now any 3 hours the check start.

I’m thinking of adding the service to some program like pacman or manjaro-system to make it reach even the old installations. Toughts ?

Personally, I wouldn’t do that. Have it running as a pacman hook after updating, yes — that’s where it matters — but I for one wouldn’t want to have it running as a timer.

4 Likes