Opened 13 months ago

Last modified 13 months ago

#15567 new bug

security of package environment files

Reported by: joeyhess Owned by:
Priority: high Milestone: 8.6.1
Component: Compiler Version: 8.2.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by joeyhess)

ghc will read package environment files owned by other users than the current user, in directories below the current directory. So using ghc in shared directories like /tmp is now a security concern.

joey@darkstar:/tmp/test/sub>ls -l  ../../.ghc.environment.x86_64-linux-8.2.2 
-rw-r--r-- 1 mail mail 9 Aug 25 15:03 ../../.ghc.environment.x86_64-linux-8.2.2
joey@darkstar:/tmp/test/sub>cat ../../.ghc.environment.x86_64-linux-8.2.2 
joey@darkstar:/tmp/test/sub>ghc --make foo
<command line>: cannot satisfy -package-id outdated
    (use -v for more information)

I suppose this could at least be used to trick ghc into building against an older version of some package that was updated with a security fix. It might be possible to exploit in other ways, perhaps by pointing to a backdoored build of a package?

Change History (4)

comment:1 Changed 13 months ago by joeyhess

Description: modified (diff)

comment:2 Changed 13 months ago by svenpanne

Just another indication that one should explicitly opt-in into reading environment files, and not be forced to opt-out... I really hope that GHC's default behavior will be fixed in this respect.

comment:3 Changed 13 months ago by hvr

Sven, we don't have to throw the baby out with the bathwater -- for ghc env files to achieve the goal they were invented for they have to be honoured by default, otherwise they become too tedious to use that we can just as well give up on them -- it's like asking to have to opt into .ghci files; we can just simply fix the code to follow a similar logic like we did for .ghci files: only read them if the permission/ownership are sensible.

comment:4 Changed 13 months ago by svenpanne

The environment files were not "invented" in any way, they are just an idea copied from Python (probably) in a bad way. The crucial point is: To keep things reproducible and don't accidentally break perfectly fine Haskell scripts/tools/etc., which just happen to be run in the "wrong" working directory, opt-out is the wrong way to go. I totally understand the motivation of having a "virtual environment"-like feature, which is a great thing in itself, but by all means: Make this explicit, otherwise it's a horrible misfeature, something which other language infrastructures have already learned. I think I'm not alone in this view, see

I really challenge the idea that virtual environments would be useless when you have to opt-in: This is what e.g. Python people happily do. Clearly documenting e.g. cabal new-repl, cabal new-run and a few words about how to use direnvfor people wanting some automatism should be doable. Combine this with opt-in as the default, and everybody will be happy...

Note: See TracTickets for help on using tickets.