[pacman-dev] permission handling

[Xavier]

On Fri, Oct 05, 2007 at 04:37:54AM +0200, Miklos Vajna wrote:
> On Thu, Oct 04, 2007 at 01:18:11PM +0200, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
> > pacman can quit (any may ignore -y). libalpm could also inform the caller
> > funtion about "Operation not permitted" with an error-type.
> 
> this is what PM_ERR_BADPERMS is about. this has been disabled in
> pacman.git's c22e381a (maybe earlier)
> 
> (in pacman-g2 if the frontend does not have any such checks, then the
> commit of the transaction fails with this error code)
> 

Rather earlier : cdb46ef3 (funny enough, the realpath stuff I mentioned in
    another thread was introduced there too)

I don't know what this ACCESS stuff was about, but that's not at all how I
understood Nagy's comment.
See his previous comment :
http://www.archlinux.org/pipermail/pacman-dev/2007-October/009521.html

What he's suggesting is that pacman returns a PM_ERR_BADPERMS on every
read / write error.
Not just a simple root check, like this ACCESS stuff appears to be.
Besides, this basic root check is already done in the frontend,
so what's the point of having it in the backend as well?

Ideally, pacman should have a real transaction model. That is, it's not
possible to do a half transaction.
So either, it should be able to detect that everything will go fine before
starting.
For having an idea about how easy that is, see for example the freespace
check Dan had to remove : ed13ac2c
Or the remove check that was introduced because of bug 5887 with commit
a94e22d9, and which is totally unreliable :
* bug 7652
* http://www.archlinux.org/pipermail/pacman-dev/2007-August/009150.html

The second possibility I see would be the ability to rollback, but that might
be even harder.
As Nagy mentioned, in the common case, that ability to roolback might not be
needed. If pacman fails on the first read/write error, it'll probably be
early enough in most cases.