[RPL/2] Error in half-compilation

DEMAINE Benoit-Pierre benoit at demaine.info
Mar 19 Juin 14:10:13 CEST 2007


BERTRAND Joël wrote:
> 	Please don't send to mailing list your log files. I think you can 
> upload these logs on a web site.

Bot said I was to be moderated, and moderator validated my email.

> 
> 	Pre8s _should_ work even on gentoo. You are not able to build a regular 
> pre8s due to a corrupted file created by libtool. It occurs when libtool 
> crashes (internal error or TERM signal). If you remove 
> .deps/librpl_la-algebre_lineaire1.conv.Tpo, you can rebuild a pre8s.

I am not going to maintain deprecated version.

> 	For pre8w, I suspect a bug in Gentoo build process. I don't have any 
> gentoo box, only debian/sparc and Solaris/sparc.

I wrote the process, and we discussed about it long time ago (end 2006 
from memory). I am waiting for ebuild to be merged with distro (may 
never happen in facts ...)

Are you sure you dont get confused version V and W ? from ML, latest 
version was V, then you proposed a patch, but on mirors I could find W 
(which was not mentioned in ML). To me, W *is* latest.

> It was a security issue 
> (code injection) in RPL/2. If you install RPL/2 in /usr and your PATH is 
> define as /usr/local/bin:/usr/bin, and a user can write on 
> /usr/local/bin, this user can write its own rplpp (RPL/2 preprocessor). 
> He can put it in /usr/local/bin, and if a root cron job (for example) 
> starts a RPL/2 routine, this user can obtain root privileges.
> 
> 	Thus, path of rplpp is hard coded and defined by d_exec_path. It should 
> be /usr/local/bin or /usr/bin, not 
> /var/tmp/portage/doublehp/rpl2-4.0.0.8.0.23/image//usr.

That was one of the thing we discussed for hours you and me.

/var/tmp/portage/doublehp/rpl2-4.0.0.8.0.23 is the temp dir for 
compilation; /image is the target directory (installation path); your 
make install is told to install there; problem is that (I had the same 
problem for other programs) you hard code the install dir and assume it 
will be the execution dir, what is false ... what is ALWAYS false on Gentoo.

Let's give a non Gentoo example:
A is big opwerfull AMD64 box, B is small pentium. You may want to use A 
to comile RPL2, then install it on B; one of the many ways to do it 
would be to nfsmount B on A; then, the install path when compiling on A 
would be /mnt/nfs/A/ when runtime path on A would be /

This story tells you an other case where install path is not runtime path.

For other apps where I had the problem, developer had to add a new 
argument to the build process, so that distros and users can 
differentiate these.

On Gentoo, the systematical use of a sandbox make compleetely impossible 
to install the program directly onto / . Thus, on Gentoo, the install 
dir is ALWAYS different from the execution dir. App installs in 
/var/tmp/portage/App-kind/APP/image/ then, the distro moves it to / 
later on, after some verification (testing, eventually scanning against 
bad linking, virus detection is also possible ...). App is compiled as 
root, but root from sandbox can not write to / .

Reading ./configure --help, I discover big ambiguity:

Installation directories:
   --prefix=PREFIX         install architecture-independent files in
                           PREFIX [/usr/local]
   --exec-prefix=EPREFIX   install architecture-dependent files in
                           EPREFIX [PREFIX]

What looks strange to me; I think that you assume install dir will be 
execution dir, and hardcode PREFIX in libs.

Can you confirm ?

what would be your configure option in the case I described for machines 
A and B ?

-- 
  >o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)



Plus d'informations sur la liste de diffusion RPL2