Mageia forum

All has been quiet on the update front for a while and yesterday I became curious and ran the MCC update program only to find a lot of updates sitting there. This morning I watched on the journal as the mga-applet ran urpmi.update and then, curiously, ended without its usual declaration of either "updates are current" or "new updates are available". And, again, of course, there was no notification via the desktop applet. So any of you who have not seen any updates over the last few days might want to start checking manually via MCC. - George

Aha.....in your other post/topic where you have some 'niggling' issues with grub2 and btrfs after converting to btrfs, I've suggested that you "grub-install" again after lastest updates to rc4 (grub2 is now quite good in rc4), so you might want to try

Code: Select all

# grub2-install --recheck /dev/sda
# update-grub2


ps: will do no harm if your system is already fine.
ps: what this does is to make sure that any change (btrfs/uuid/boot....) you make will be reflected properly in grub2.
ps: 'update-grub2' may be superflous after 'install-grub2' but...just to make sure.

Thanks very much for the tip. I will look into that as soon as I get a chance. At this point I have just set up a back up script to run on anacron which mounts a backup drive on a schedule, does daily, weekly or monthly backups and then unmounts the drive. So I am busy working the bugs out of that right now. (I am writing the backups to an AFS 4TB unpartitioned drive formatted btrfs to the raw drive using subvolumes.) So far that is going splendidly. But when I get the chance I will take another look at the sporadic boot failure issue and the stuff you are suggesting. Thanks! - George

In order to function properly mgaapplet must access the system rpm databases with only user level permissions. Therefore the directory /var/lib/rpm has its permissions set at 755 by the "rpm" package. This got flagged on my system as a security breach which I fixed by removing open access to the "world", resetting permissions on /var/lib/rpm to 750. That is what killed mgaapplet. So all users should be aware that the price of this convenience is opening up access to your package database to anyone who might "drop in". Of course, not keeping packages up to date is a security risk in and of itself. I can see two possible solutions to this problem. The easiest would be to set permissions on /var/lib/rpm to 750 and then to add group rpm to user's group permissions. That is the approach I am going to test out next. I have opened a bug report against /var/lib/rpm default permissions (https://bugs.mageia.org/show_bug.cgi?id=9981).

This solution appears to be working. - George

And the official answer is:

--- Comment #2 from David Walser <luigiwalser@yahoo.com> ---
This is already handled by msec. In the secure level the rpm stuff is only
readable by the rpm group. In the standard level, all the 755/644 means is
that regular users can query the package database.

I am not sure I quite understand what is going on here. I feel very uncomfortable when security issues are not straightforward and become convoluted. Seemingly Red Hat has a policy that nothing in /var/lib should be open to the world at the directory level. Apparently Mageia creates an exception for this directory. That makes me uncomfortable. But such is life.

Why do you imply that RedHat security policies directly apply to Mageia?
Also, read access to the rpm DB provides for which security problems in particular?
Read access != write access.

And it's pretty straightforward. If you don't want your users to query the rpm db, then change the default
permissions, or use the msec Secure level for your whole system, if standard settings are not enough for you.

Doktor, Actually, what I wrote was not even correct. Red Hat DOES NOT have any policy dictating read permissions for /var/lib. The Red Hat policy, instead, is related to home directories and /var/lib/rpm is designated as home directory for rpm, which is quite different from a regular user. So this is NOT Mageia's problem OR Red Hat's problem. What happened is that I tried to "fix" something without thoroughly investigating the underlying issue. So you ARE correct. I apologize on this one. - George

Additionally, I just learned that the tool I was using to check these permissions is not even supposed to be checking /var/lib. All that was needed was to modify a config file to list rpm as a "system account" as opposed to a "user account". Again, I apologize for this. Even after all the years I have spent on Unix and Linux, I am still learning.

No need to aplogogize
FWIW, also you should be aware of https://bugs.mageia.org/show_bug.cgi?id=2808 (sectools has not specific policy or a policy adapted to Mageia, it just uses the default)

Its even worse than that. sectools is at this point unmaintained. I REALLY like it, it is, in my opinion, very user friendly. At this point I have actually reworked some things in the config files to make it more accurate. I am also thinking about trying to learn enough python to actually fix some of the scripts (the fact that it examines symlinks whose permissions are meaningless, for example, instead of examinging the perms on the targets. I know we have msec and I actually DO use msec as well. But different tools taking different approaches tend to expose more issues, along, of course, with presenting more false positives like the one I got taken in by. But false positives are not limited to sectool. msec has its own problems with false positives: https://bugs.mageia.org/show_bug.cgi?id=10004.

Well, sectool was always unmaintained. I know it pretty well, because i imported it to fix some dependency issues, then adjusted some msec configs,
that was some huge trouble and work involved. If you're interested, you're welcome to check https://bugs.mageia.org/show_bug.cgi?id=2255

Well I am chipping away at sectool, gradually resolving some of the more glaring inconsistancies with msec. Unfortunately, part of the problem stems from the way in which the bash test scripts were written, for example, using builtin system account lists rather than intelligently computing them by UID and /etc/login.defs. This sort of thing tends to make sectool very high maintenance. Also its penchant for meaningless permission testing on symlinks instead of testing the targets. Fixing those sorts of issues will require some deeper surgery. But at this point I am working at it and will pass the result back up when I put enough together to be worthwhile. - George