local path disclosure

[accursoft]

When compiling cabal-install, the path to my ~/.cabal directory is hard-coded several times in the executable. Is it possible to avoid this?

My use case is a private server that's compiling cabal-install, then deploying it to less privileged servers which shouldn't know anything about the private server's file system.

[23Skidoo]

Can you be more specific? We use $HOME/.cabal, so the absolute path shouldn't be hardcoded.

[accursoft]

$ strings ~/.cabal/bin/cabal | grep <censored>
/home/<censored>/.cabal/etc
/home/<censored>/.cabal/libexec
/home/<censored>/.cabal/share/x86_64-linux-ghc-7.6.3/cabal-install-1.18.0.2
/home/<censored>/.cabal/lib/x86_64-linux-ghc-7.6.3/cabal-install-1.18.0.2
/home/<censored>/.cabal/bin
/home/<censored>/.cabal/etc
/home/<censored>/.cabal/libexec
/home/<censored>/.cabal/share/x86_64-linux-ghc-7.6.3/HTTP-4000.2.8
/home/<censored>/.cabal/lib/x86_64-linux-ghc-7.6.3/HTTP-4000.2.8
/home/<censored>/.cabal/bin
/home/<censored>/.cabal/etc
/home/<censored>/.cabal/libexec
/home/<censored>/.cabal/share/x86_64-linux-ghc-7.6.3/Cabal-1.18.1
/home/<censored>/.cabal/lib/x86_64-linux-ghc-7.6.3/Cabal-1.18.1
/home/<censored>/.cabal/bin

[hvr]

This sounds like it's related to #462 and/or #1542

[23Skidoo]

These strings come from the auto-generated Paths_ module. Compiling Cabal and cabal-install with -split-objs should fix this. You can enable split-objs in ~/.cabal/config.

@hvr

This sounds like it's related to #462 and/or #1542

Yes, tangentially.

[accursoft]

I built everything with --enable-split-objs, and the first 5 offending strings (i.e. those not imported from other packages) are still present. Probably because Main.hs uses Paths_cabal_install.

[23Skidoo]

Apparently we use getBinDir, which references binDir.

[accursoft]

Perhaps the Paths_ dirs should be in a configuration file, instead of hard coded? That would make it easier to relocate (without having to set environment variables on the target to override), and solve the local path disclosure.

[23Skidoo]

I removed the reference to getBinDir, but for some reason the strings are still present. The GHC documentation says that --split-objs only makes sense for libraries: apparently the split object files are not used when linking executables. That is, the linker is fed dist/build/cabal/cabal-tmp/Distribution/Client/Dependency/TopDown/Types.o instead of dist/build/cabal/cabal-tmp/Distribution/Client/Dependency/TopDown/Types_o_split/Types__*.o.

One possible solution is to make cabal-install a library, but we don't want to do this right now. Another is to fix GHC.

[dcoutts]

@accursoft note that you can specify the --prefix when you build something. Yes, this location may be hard-coded into the executable, because we do not yet support relocatable packages.

The right way to prepare something for deployment is:

cabal configure --prefix=${the install location on the target machine}
cabal build
cabal copy --destdir=${image}

Then you tar up the image directory and deploy that to the target machine. Directories under the prefix you specify will be included in the executable.

I think the other aspects are covered by #462.

[23Skidoo]

@dcoutts

Yes, this location may be hard-coded into the executable, because we do not yet support relocatable packages.

It is hardcoded, but is not actually used anywhere. The cabal-install executable is relocatable in practice.

[mietek]

@23Skidoo: By “anywhere”, do you mean the cabal-install source code, or also the GHC run-time? Could other executables be non-relocatable, without a specific reason in their source code?

[23Skidoo]

@mietek The former, but since these symbols come from the Cabal-generated Paths_ module, the GHC runtime can't know about them either.

Could other executables be non-relocatable, without a specific reason in their source code?

Only if an executable uses these paths in some way, e.g. if it accesses data files with getDataDir instead of file-embed.