[Rpm-maint] Feature request: Improved speed for 'rpm -qa'

James Olin Oden james.oden at gmail.com
Wed Dec 20 14:36:09 UTC 2006


On 12/19/06, Bill Nottingham <notting at redhat.com> wrote:
> James Olin Oden (james.oden at gmail.com) said:
> > I always thought that it was enough to check the header at install
> > time when it was being inserted into the DB, but now I can see why one
> > might want to do this check even on queries, as a query is often used
> > as input into some larger process.  The person running the "process"
> > may have all authority to do what they are going to do based on the
> > inputs from the rpm DB, and have no malicious intent, but rogue data
> > may make them do something they would not have otherwise done.
>
> But access control to the database itself would seem to be better
> done at a higher level, such as a SELinux policy, or even plain
> old ACLs and permissions, rather than expensive checks on every
> database access.
Its not about access control in this case, its about trust of what is
in the database.
You can controll access with SE Linux all you want but there is no way
for me to tell that someone installed a rogue package without checking
digests at some point (maybe they were in a hurry) and that now I'm
looking at infomation from that rogue packets header without checking
digests on query.

That said there could be a smarter way.  For instance, if one flagged
the db as unsafe if someone installed without digest checking, then
one could only check the digests on an unsafe database.  This though
as I think of it does not do very well because one could update the DB
outside of rpm.  Their may be a way of detecting this though, but I
don't know how expensive such a check would be but I suspect just
about as expensive as checking the sigs on all the headers.

Ultimately, though, I'm thinking that we are getting into the area of
policy which RPM unfortunately allows one to only crudely express.
Basically, you have some who want that level of security at the cost
of the longer query times, and some that do not.  I suspect one can
turn this off with some macro, but what rpm really needs is some way
to administratively configure it (preferably without setting bunches
of macros, and preferably through the use of some CLI).  Some things
like how berkely DB is used work well with macros (because people
don't typically change that for one), but other things could be better
represented in some documented consistent manner through an intuitive
use interface (such as to autorollback or not, do I check digests on
queries, and so on).

Cheers...james
>
> Bill
>



More information about the Rpm-maint mailing list