[pacman-dev] installing a package as user (permission problems)

[Dan McGee]

On 7/7/07, Xavier <shiningxc at gmail.com> wrote:
> Should pacman allow installing a package as user ?
> It looks quite hard to check for all permissions
> before doing anything.
> And if permissions are checked on the fly, and at one point it fails,
> it looks hard to revert what has been done.
> For example, suppose an user wants to install foo-1 package,
> and has write access to everything but $dbpath/local/foo-1/
> pacman will be able to install the package, extracting all files
> on filesystem, but it won't be able to add the package in the database.
> So the package will be installed, but not recorded in the db.
>
> A permission problem can also appear earlier, eg during the extraction of
> files. Maybe all files from the package can be extracted except one,
> which needs to be installed in a directory without write access.
>
> That looks quite complicated to handle.
>
> Oh, I just remembered Dan's permissions branch :
> http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=b06c89e3e5c8a1daae1b6fdab504bb8a9301cfc9
>
> "Remove geteuid calls and things related to uid checking in anticipation
> of reimplementing a more robust permissions checking system. This will
> allow libalpm to be used in situations where we do not always have root
> on a system (cygwin, dreamhost, etc.)."
>
> More robust permissions checking system, that would be cool. :)
> To Dan : what you had in mind would solve the problems above ?

Ha- dreams and hopes, that is about it. :)

My most recent thought- ensure we have permissions on the DB. If we
have this, then assume we have permissions on the file system.
Obviously assumptions suck, but I'm trying to think of another way
that we can have a user be able to use pacman from the install point
of view. Right now the strict check for root holds us back here.

Interestingly, I already found a problem earlier today that stems from
this type of issue.

$ ./src/pacman/pacman -v --config=etc/pacman.conf.save --debug=1
[00:20:09] debug: config: attempting to read file etc/pacman.conf.save
[00:20:09] debug: config: new section 'options'
[00:20:09] debug: option 'root' = /
[00:20:09] debug: config: rootdir: /
[00:20:09] debug: option 'dbpath' = /usr/local/var/lib/pacman/
[00:20:09] debug: option 'lockfile' = /usr/local/var/lib/pacman/db.lck
[00:20:09] debug: config: dbpath: /usr/local/var/lib/pacman/
[00:20:09] debug: option 'cachedir' = /usr/local/var/cache/pacman/pkg/
[00:20:09] debug: config: cachedir: /usr/local/var/cache/pacman/pkg/
[00:20:09] debug: config: logfile: /usr/local/var/log/pacman.log
[00:20:09] debug: config: holdpkg: pacman
[00:20:09] debug: config: holdpkg: glibc
[00:20:09] debug: config: new section 'current'
[00:20:09] debug: registering database 'current'
[00:20:09] debug: database dir '/usr/local/var/lib/pacman/current'
does not exist, creating it
[00:20:09] error: failed to make path
'/usr/local/var/lib/pacman/current' : Permission denied
[00:20:09] debug: returning error 2 from _alpm_db_register :
unexpected system error
[00:20:09] debug: returning error 11 from alpm_db_setserver : database
not initialized

Notice that we attempt creation of these paths even when run as a
normal user, just because this is one of the steps in registering a
DB. This is a problem that needs fixing, and I expect to find quite a
few more things like these in the coming days if I do a bit more of my
edge case testing that has been lacking. I finally got my chroot all
set up to do some serious damage with the pacman GIT version.

-Dan