[pacman-dev] RootDir using symlinks -> problem

[Xavier]

On Thu, Oct 04, 2007 at 10:37:36PM +0200, Xavier wrote:
> Actually, there is a bigger issue here.
> 
> This code assumes that DBPath depends on RootDir, while this is not the case
> anymore.
> 
> So probably the install scriptlet needs to be put somewhere under RootDir,
> maybe somewhere under RootDir/tmp/, like the others.
> So that when we chroot in RootDir, it's still available inside the chroot.
> Would this be the correct solution?
> 

Dan and Aaron apparently discussed that on IRC.
I am still a bit confused though..

Apparently, Dan is for flexibility, so having the possibility to have the
dbpath outside rootdir. And so, in this case, my patch should probably be
applied. Unless there are many other hidden dependencies, where the code
assumes that dbpath (or others) are under rootdir?

On the other hand, Aaron said having the possibility to have DBPath outside
RootDir is useless, and that it doesn't make sense.
The final proposal is apparently just issuing a warning when the DB dir is
outside the rootdir.

I am not sure if I really like this, I would prefer choosing one way or the other,
instead of having something unstable in the middle.
So either deciding that all paths should be independent, and trying to
implement this in pacman, or deciding that all paths should be relative to RootDir,
and enforce this in pacman (which was already done in 3.0, wasn't it?)

Maybe using realpath everywhere + issuing a warning is still an acceptable
solution. I'm not the one who decides anyway :)

> 
> The second problem with this chroot is that it requires root access.
> So the RootDir check here is wrong for a common -U / -S operation :
> 
> 778   if(myuid > 0 && !strcmp(alpm_option_get_root(), "/") && needs_transaction()) {
> 779     /* special case: ignore root user check if -r is specified, fall back on
> 780      * normal FS checking */
> 
> If one try to install stuff in an alternate root dir as user, pacman will silently fail to run the scriptlets,
> because it can't chroot. So don't you think this check should just be removed?
> 

And what about this? I made a trivial patch for it, but not sure if it's correct.