Bug#554170: passwd: handle /var/backups/passwd.bak

[Justin B Rye]

Package: passwd
Version: 1:4.1.4.2-1
Severity: wishlist

At present /etc/cron.daily/standard maintains backups of /etc/passwd
(and so on) in /var/backups. If this is something that it's
generally agreed is worth doing, it would seem to make more sense
for the cronjob handling it to belong to the package passwd, not
cron itself.

I'd like to propose that passwd should copy the approach adopted by
dpkg, which now (since version 1.15.4.1) does the work of
maintaining backups in /var/backups for itself, checking first to
see if there's already a backup in place.

This is part of an attempt to retire /etc/cron.daily/standard and
eliminate a redundant dependency - see bug #537073.

The section in /etc/cron.daily/standard currently looks like this:
----------------------------------------------------------------------
#!/bin/sh
[...]
bak=/var/backups
[...]
#
# Backup key system files
#

if cd $bak ; then
cmp -s passwd.bak /etc/passwd || (cp -p /etc/passwd passwd.bak &&
chmod 600 passwd.bak)
cmp -s group.bak /etc/group || (cp -p /etc/group group.bak &&
chmod 600 group.bak)
if [ -f /etc/shadow ] ; then
cmp -s shadow.bak /etc/shadow || (cp -p /etc/shadow shadow.bak &&
chmod 600 shadow.bak)
fi
if [ -f /etc/gshadow ] ; then
cmp -s gshadow.bak /etc/gshadow || (cp -p /etc/gshadow gshadow.bak &&
chmod 600 gshadow.bak)
fi
fi

if cd $bak ; then
if ! cmp -s dpkg.status.0 /var/lib/dpkg/status ; then
cp -p /var/lib/dpkg/status dpkg.status
savelog -c 7 dpkg.status >/dev/null
fi
fi
[...]
----------------------------------------------------------------------
The new /etc/cron.daily/dpkg cronjob looks like this:
----------------------------------------------------------------------
#!/bin/sh

# Backup the 7 last versions of dpkg's status file
if cd /var/backups ; then
if ! cmp -s dpkg.status.0 /var/lib/dpkg/status ; then
cp -p /var/lib/dpkg/status dpkg.status
savelog -c 7 dpkg.status >/dev/null
fi
fi
----------------------------------------------------------------------
So you could create a /etc/cron.daily/passwd like this:
----------------------------------------------------------------------
#!/bin/sh

# Back up the 7 last versions of passwd and related files
if cd /var/backups ; then
cmp -s passwd.bak /etc/passwd || (cp -p /etc/passwd passwd.bak &&
chmod 600 passwd.bak)
cmp -s group.bak /etc/group || (cp -p /etc/group group.bak &&
chmod 600 group.bak)
if [ -f /etc/shadow ] ; then
cmp -s shadow.bak /etc/shadow || (cp -p /etc/shadow shadow.bak &&
chmod 600 shadow.bak)
fi
if [ -f /etc/gshadow ] ; then
cmp -s gshadow.bak /etc/gshadow || (cp -p /etc/gshadow gshadow.bak &&
chmod 600 gshadow.bak)
fi
fi
----------------------------------------------------------------------
Or preferably something more like this:
----------------------------------------------------------------------
#!/bin/sh
cd /var/backups || exit 0
for FILE in passwd group shadow gshadow; do
test -f /etc/$FILE || continue
cmp -s $FILE.bak /etc/$FILE && continue
install --preserve-context -pm 0600 /etc/$FILE $FILE.bak
done
----------------------------------------------------------------------
But the point here is to get it under the control of the developers
most likely to know better.
--
JBR
Ankh kak! (Ancient Egyptian blessing)

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Nicolas François]

Hello,

On Tue, Nov 03, 2009 at 03:19:10PM +0000, Justin B Rye wrote:
>
> The section in /etc/cron.daily/standard currently looks like this:
> ----------------------------------------------------------------------
> #!/bin/sh
> [...]
> bak=/var/backups
> [...]
> #
> # Backup key system files
> #
>
> if cd $bak ; then
> cmp -s passwd.bak /etc/passwd || (cp -p /etc/passwd passwd.bak &&
> chmod 600 passwd.bak)
> cmp -s group.bak /etc/group || (cp -p /etc/group group.bak &&
> chmod 600 group.bak)
> if [ -f /etc/shadow ] ; then
> cmp -s shadow.bak /etc/shadow || (cp -p /etc/shadow shadow.bak &&
> chmod 600 shadow.bak)
> fi
> if [ -f /etc/gshadow ] ; then
> cmp -s gshadow.bak /etc/gshadow || (cp -p /etc/gshadow gshadow.bak &&
> chmod 600 gshadow.bak)
> fi
> fi

> [...]

> Or preferably something more like this:
> ----------------------------------------------------------------------
> #!/bin/sh
> cd /var/backups || exit 0
> for FILE in passwd group shadow gshadow; do
> test -f /etc/$FILE || continue
> cmp -s $FILE.bak /etc/$FILE && continue
> install --preserve-context -pm 0600 /etc/$FILE $FILE.bak
> done
> ----------------------------------------------------------------------

Is there a reason you changed cp + chmod to install --preserve-context ?

The --preserve-context causes warnings (which would be sent daily) on
non-SELinux machines.

Thanks in advance,
--
Nekral

[Justin B Rye]

Nicolas François wrote:

> Justin B Rye wrote:
>> [...]
>> Or preferably something more like this:
>> ----------------------------------------------------------------------
>> #!/bin/sh
>> cd /var/backups || exit 0
>> for FILE in passwd group shadow gshadow; do
>> test -f /etc/$FILE || continue
>> cmp -s $FILE.bak /etc/$FILE && continue
>> install --preserve-context -pm 0600 /etc/$FILE $FILE.bak
>> done
>> ----------------------------------------------------------------------
>
> Is there a reason you changed cp + chmod to install --preserve-context ?
>
> The --preserve-context causes warnings (which would be sent daily) on
> non-SELinux machines.

Oh, sorry! I'm even using a non-SELinux kernel right now - so that
tells me which machine I must have been on when I did my testing.
Okay, scratch that "--preserve-context".

Usually I'd go for the "install -pm 0600" approach because it has
the advantage of not leaving the permissions wrong for a moment;
but in this case, that only means there's a window of opportunity
for members of the shadow group to read data they could already see
in the original file... In fact it's not quite clear to me why the
permissions would _need_ to be tightened up.

Using the same install command on all these files also loses the
opportunity to preserve the shadow group-ownership on /etc/*shadow.
But then again if you're stripping the group-readable bit why would
you _want_ to preserve the group-ownership?

Anyway, as I say, the whole point of this bugreport was that the
Shadow Cabal would know best what's appropriate here...

--
JBR
Ankh kak! (Ancient Egyptian blessing)

--