[pacman-dev] permission handling

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 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.