Re: Adding file permissions to /var/lib/dpkg/*.list
Hi,
On Fri May 4 2007 02:55:31 pm you wrote:
> On 04/05/07, Bruce Sass <bmsass@shaw.ca> wrote:
> > On Fri May 4 2007 11:41:11 am Conrado Buhrer wrote:
> > > Hello all,
> > >
> > > I would probably be a nice feature to have file permissions added
> > > to /var/lib/dpkg/*.list files for several reasons.
> > >
> > > In case of mistakes all file permissions could be restored.
> >
> > What kind of mistakes?
>
> Well, some guy entered our chat channel #linux on IRCnet with having
> run a script he made to recursively set permissions on a directory
> tree. Unfortunately he broke his whole distribution. Its a common
> newbie mistake to change permissions without thinking about the
> consequences. On debian you could not write a script on your own to
> fix this without having to download every package again, or packages
> on a cd, etc.
An even more common newbie mistake is not making backups before you
start muck'n with the system; making backups can help recover from a
wider variety of mistakes than simply keeping track of permissions.
I can't help wondering... if dpkg did keep track of permissions, would
it interfere with sysadmins who want to change the packaged
permissions. At the very least there would need to be a way to update
the package DB with locally set permissions.
> Other problems might be archiving errors where you gave the wrong
> parameters to tar, ar, etc.
I'm not sure I understand that point. Wouldn't a `spot backup' utility
serve the same purpose and be more generally applicable (instead of
just being useful only with packaged files)?
By "spot backup" I'm thinking of a utility which would let an admin
indicate which dirs or packages they are going to be playing with,
those then get tar'd or dpkg-repack'd so changes can be easily rolled
back if they don't work out.
> > > It would facilitate installed package verification,
> > > eliminating the need for tripwire.
> >
> > Tripwire does more than keep track of permissions.
>
> True, tripwire does much more. I couldn't say it would eliminate
> tripwire. I shouldn't have put it that way. But it would help to
> quickly fix some situations and prevent you from having to do a full
> re-install.
True, but making a backup before playing does the same thing and doesn't
require overhead in the package management subsystem to accommodate
non-package management operations.
> > > Perhaps you can think of more.
> >
> > I'm having trouble thinking of the two or three (far less
> > than "several") reasons you've mentioned.
>
> Well, I think you can run already run md5sum checks on your whole
> Debian install from your own drive, it only seems reasonable to me to
> also be able to set/check the appropriate permissions as well.
I think it is reasonable to include md5sums in a package because they
contribute to security and ease package management, and it would be
unreasonable to have all systems run the exact same calculations at
install-time to get those benefits. md5sums would also be needed for
fine grained (per-file) upgrades, which has been on Debian's wishlist
for as long as I can recall (10+ yrs).
I don't think it is reasonable to include file permissions in the
package because either the info is already part of the package (without
calculation) or is determined by a script at install-time (can't be
packaged), and the info is not needed for managing packages (which
should be dpkg's sole purpose).
> > > RPM does it, Solaris pkg does it, AIX supports it. Why not dpkg?
> >
> > I don't know.
> > Why do RPM, Solaris and AIX pkg managers keep track of permissions;
> > what kinds of operations can those other pkg managers do which dpkg
> > is prevented from doing because it doesn't keep track of
> > permissions?
>
> Well, I've said that you can reset all file permissions from a
> package install standard. I know RPM at least can do that with a
> single command. I wouldn't care if dpkg had the added functionality
> to do that as of yet because I can code the script to fix the perms,
> but not without having that little bit of extra info in the *.list
> files, or downloading each .deb again.
OK. I think it would be better to achieve that by hooking a script which
records permissions into APT. e.g.:
--- /etc/apt/apt.conf.d/??permissions (cut'n'edit from 90debsums) ---
DPkg::Post-Invoke { "if [ -x /usr/bin/debpermissions ];
then /usr/bin/debpermissions --record; fi"; };
---
:) dpkg and the Maintainers don't need to get involved
:) development could proceed at its own pace
:) may be able to discover info dpkg doesn't know about
:) doesn't get forced on those who don't want/need it
:( doesn't work with dselect-only systems
There is the big question of whether it is possible to reliably record
the proper permissions in all cases... dpkg currently can't do it
because scripts can modify stuff after it has been installed, and I
don't think APT can guarantee a hooked in script will run after all
install spawned scripts have finished. At best you'll have an
incomplete picture, at worst the wrong info (with the potential to mess
up unrelated [to where the "mistakes" were made] parts of the system).
- Bruce
-------------------------------------------------------
Reply to: