On Fri, Apr 30, 2004 at 04:24:49PM -0400, James Olin Oden wrote: > > It would seem to me that the non-priv side would need to do all the conflict > > resolution in order to insure that nothing stupid will happen (IF conflict THEN > > show_user_the_Problem) before invoking the root process. > > > > Now, I suppose I could just pass off the list of new packages to install/upgrade > > and assume that the root process will reach the same conclusions as the non-root > > process. But we all know ASSUME makes an ASS of U and ME. > > > That seems reasonable, I am not sure but I think you can run rpmtsOrder() > and rpmtsCheck() as a non-privileged user, such that you could do this > before sending the data on what packages should go in the transaction to > the priviliged process. > Sure you can. Both of rpmtsCheck() and rpmtsOrder() require read permission on /var/lib/rpm, no other privs (like chroot(2)) needed. > > P.S. I am going to test the above...but I am experiencing some minor > difficulties. > Well, you need write access to /var/lib/rpm/__db* to create locks even if reading technically, but one can survive quite well w/o the ability to create shared locks. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj@xxxxxxxxxx (jbj@xxxxxxx) Chapel Hill, NC _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
