-eventlog / -debug should imply -rtsopts

[duncan]

The -eventlog flag links the program to the threaded rts. The eventlog is only generated when using the -l RTS flag, but by default we get

$ ./foo +RTS -l
Setup: Most RTS options are disabled. Link with -rtsopts to enable them.

You have to use both -eventlog and -rtsopts to be able to run with +RTS -l.

I think -eventlog should imply -rtsopts because it's pointless to use the -eventlog way if one never uses the runtime flag +RTS -l.

The -rtsopts was added as a security measure, so that by default the runtime +RTS -RTS options would not be available. Since -eventlog is a non-default option then I think it is also safe from a security POV to have it imply -rtsopts.

For the security paranoid, at most, one could consider in the userguide where -rtsopts is mentioned and the security issue pointed out, that it could also mention what other flags imply -rtsopts.

BTW, I tried making a patch for this, but the -eventlog flag is a static flag while -rtsopts is a dynamic flag and it appears hard to make one imply the other (the only case where that is done is labeled as a hack).

[igloo]

It might make more sense to make "-l" an rtsOptsSafeOnly flag.

It isn't really safe, as it writes a file, but allowing that mildly unsafe flag (when linked with -eventlog) may be better than allowing all unsafe flags.

[igloo]

See also #4913.

[simonmar]

This was fixed:

commit 8c7ad0bd5bf1e7f62f44784cc889e8ee585b8d08

Author: Duncan Coutts <duncan@well-typed.com>
Date:   Thu Oct 27 13:26:15 2011 +0100

    Change what +RTS options are available by default
    
    Ticket #3910 originally pointed out that the RTS options are a potential
    security problem. For example the -t -s or -S flags can be used to
    overwrite files. This would be bad in the context of CGI scripts or
    setuid binaries. So we introduced a system where +RTS processing is more
    or less disabled unless you pass the -rtsopts flag at link time.
    
    This scheme is safe enough but it also really annoies users. They have
    to use -rtsopts in many circumstances: with -threaded to use -N, with
    -eventlog to use -l, with -prof to use any of the profiling flags. Many
    users just set -rtsopts globally or in project .cabal files. Apart from
    annoying users it reduces security because it means that deployed
    binaries will have all RTS options enabled rather than just profiling
    ones.
    
    This patch relaxes the set of RTS options that are available in the
    default -rtsopts=some case. For "deployment" ways like vanilla and
    -threaded we remain quite conservative. Only --info -? --help are
    allowed for vanilla. For -threaded, -N and -N<x> are allowed with a
    check that x <= num cpus.
    
    For "developer" ways like -debug, -eventlog, -prof, we allow all the
    options that are special to that way. Some of these allow writing files,
    but the file written is not directly under the control of the attacker.
    For the setuid case (where the attacker would have control over binary
    name, current dir, local symlinks etc) we check if the process is
    running setuid/setgid and refuse all RTS option processing. Users would
    need to use -rtsopts=all in this case.
    
    We are making the assumption that developers will not deploy binaries
    built in the -debug, -eventlog, -prof ways. And even if they do, the
    damage should be limited to DOS, information disclosure and writing
    files like <progname>.eventlog, not arbitrary files.

 rts/RtsFlags.c |  131 +++++++++++++++++++++++++++++++++++++++++++++++---------
 1 files changed, 110 insertions(+), 21 deletions(-)