Bug 15644

No need for two BR

*** This bug has been marked as a duplicate of bug 14516 ***

Status: NEW => RESOLVED
CC: (none) => thierry.vignaud
Resolution: (none) => DUPLICATE

Re-opening as per QA meeting. Advisory updated for bug 14516.

Current packages:

SRPM:
 - setup-2.7.20-9.4.mga4

RPMs:
setup-2.7.20-9.4.mga4.noarch

Status: RESOLVED => REOPENED
Version: Cauldron => 4
Resolution: DUPLICATE => (none)
Whiteboard: MGA4TOO => (none)

Advisory:
=========

Updated setup package fixes security issue

  An issue has been identified in Mageia 4's setup package where the
  /etc/shadow and /etc/gshadow files containing password hashes were created
  with incorrect permissions, making them world-readable (mga#14516).

  This update fixes this issue by enforcing that those files are owned by
  the root user and shadow group, and are only readable by those two entities.

  Note that this issue only affected new Mageia 4 installations. Systems that
  were updated from previous Mageia versions were not affected.

  This update was already issued as MGASA-2015-0116, but the latter was withdrawn
  as it generated .rpmnew files for critical configuration files, and rpmdrake
  might propose the user to use those basically empty files, thus leading to
  loss of passwords or partition table. This new update ensures that such .rpmnew
  files are not kept after the update.


References:
 - https://bugs.mageia.org/show_bug.cgi?id=14516
 - http://advisories.mageia.org/MGASA-2015-0116.html
 - https://ml.mageia.org/l/arc/qa-discuss/2015-03/msg00399.html

*** Bug 14516 has been marked as a duplicate of this bug. ***

CC: (none) => thkala

*** Bug 14516 has been marked as a duplicate of this bug. ***

Testing procedure... https://bugs.mageia.org/show_bug.cgi?id=14516#c73

OK'ing for Mageia 4 x86_64 as per https://bugs.mageia.org/show_bug.cgi?id=14516#c78

Whiteboard: (none) => has_procedure MGA4-64-OK

urpmi --downgrade setup
The following package has to be removed for others to be upgraded:
setup-2.7.20-9.4.mga4.noarch
 (in order to install setup-2.7.20-9.mga4.noarch) (y/N) y

I then had to manually change the ownership and permissions of the files in question so that:

ls -ll /etc/*shadow*
-rw-r--r-- 1 root root 511 Dec  9 21:35 /etc/gshadow
-rw-r--r-- 1 root root 504 Dec  9 21:35 /etc/gshadow-
-rw-r--r-- 1 root root 717 Dec  9 21:35 /etc/shadow
-rw-r--r-- 1 root root 695 Dec  9 21:28 /etc/shadow-

urpmi --media "Core Updates Testing" setup
 ftp://192.168.0.2//pub/mirror/Mageia/distrib/4/i586/media/core/updates_testing/setup-2.7.20-9.4.mga4.noarch.rpm

Which resulted in 
ls -ll /etc/*shadow*
-r--r----- 1 root shadow 511 Dec  9 21:35 /etc/gshadow
-r--r----- 1 root shadow 504 Dec  9 21:35 /etc/gshadow-
-r--r----- 1 root shadow 717 Dec  9 21:35 /etc/shadow
-r--r----- 1 root shadow 695 Dec  9 21:28 /etc/shadow-

This looks to be what is required.

OK for mga4 32

Have you tested the fact that an old rpmdrake (not the latest from updates) must not mention .rpmnew files at all for this update?

CC: (none) => stormi

No. I've removed the OK and will retest.

Whiteboard: has_procedure MGA4-64-OK MGA4-32-OK => has_procedure MGA4-64-OK

I downgraded setup and rpmdrake and reverted the ownership and permissions of the shadow and gshadow files.

I had to disable core/updates to prevent rpmdrake from updating itself.

I then used (the "old") rpmdrake-6.10.3-1 to update setup. 

There was no "upgrade" information offered and the ownership and permissions of shadow and gshadow  were correctly changed.

Is that what was required?

Yes, thanks!

Whiteboard: has_procedure MGA4-64-OK => has_procedure MGA4-64-OK MGA4-32-OK

Validating. Advisory uploaded.

Please push to 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: has_procedure MGA4-64-OK MGA4-32-OK => has_procedure advisory MGA4-64-OK MGA4-32-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2015-0162.html

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED