hushhush has asked for the wisdom of the Perl Monks concerning the following question:

Hi

My app uses a perl config file that's basically just a data structure I pull in with a do call.

I'd like to make this a binary file so it's difficult for anyone but myself or select others, to modify the configuration file. Storable would almost be fine but that's a bit too easy for someone else to read in modify and write out a new one.

Basically I'm just trying to keep the honest people honest :) there are some people who will have file level access to the app that might be tempted to modify it, rather than go through channels.

Any suggestions, this is for a persistent web app so it only needs to load once at startup.

thanks in advance

Replies are listed 'Best First'.
Re: Binary config file suggestions
by Fletch (Bishop) on Mar 12, 2009 at 13:51 UTC

    You could always compress it using (say) IO::Compress::Gzip. If you really wanted to be evil you could strip off the gzip magic number from the start (s/\A\037\213//) and then prepend it back before decompressing it with IO::Uncompress::Gunzip.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

[reply]
[d/l]
      Fletch,
      I am not sure how that helps. I think it "fails" for the same reason Storable fails. If the "bad guys" have the ability to see the perl to know it is a storable file in the first place, then they would know how to reverse the process. This is all hand wavy since I don't think we are getting the whole story.

      Assuming that the "bad guys" have the ability to read the perl script but not execute it, then I would suggest using AES encryption and storing the key in a file that can be read by the process executing the perl script but not by the "bad guy". Again, very hand wavy.

      Cheers - L~R

[reply]

        He's not looking to keep out bad guys (at least that's how I took the "Basically I'm just trying to keep the honest people honest :)" comment), but just trying to obfuscate things to prevent overeager-but-authorized users from monkeying with the shiny bits inside. Gzip'ing it and removing the magic puts an admittedly tiny speed bump in front of them.

        At least that's how I read it; he's not looking for a safe, he's looking for a way to keep the too-smart-for-their-own-good from taking a blunt object to the engine of their own car. But if it were a case of guarding against black hats then yes sound proven crypto (AES, Blowfish, yadda yadda) certainly would be the way to go.

        Update: Tweaked second para's first sentence.

        The cake is a lie.
        The cake is a lie.
        The cake is a lie.

[reply]
Re: Binary config file suggestions
by sweetblood (Prior) on Mar 12, 2009 at 15:42 UTC
    I had a similar issue with a config file that users at one point had to "manually" adjust in vi, so breaking the habit was key. Since this is a matter of "keeping honest users honest" and not preventing bad guys from access sensitive stuff, I'd go with storable, it's what I used back in 2003 and that process is still in place today. The node that brought me to that conclusion is: Obscure data

    HTH

    Sweetblood

[reply]
Re: Binary config file suggestions
by Marshall (Canon) on Mar 12, 2009 at 16:06 UTC
    This sounds like a sys admin problem. I don't know what O/S you are on, but even on MS there are ways to allow execute, but not read permissions. This is very easy to do on a *nix platform. If the "bad", but not so "bad" guys have read access to the source code, then I would say "game over".

    If this is some sort of user config file that you want to be controlled by your program (and only modified by your program), then that is different. Leave the file in plain text and put a fancy "checksum" at the end. Lots of ways to do that. Program doesn't run if "checksum" doesn't jive. Your program controls encryption keys and algorithm to generate the "checksum".

[reply]

      A simple, and for this purpose probably sufficiently robust, way to provide a 'checksum' is to use the MD5 of the original text concatenated with some seed text. In fact if the seed text is the source for the program you can check both the program and the config file for tampering.

      True laziness is hard work
[reply]
      there are ways to allow execute, but not read permissions. This is very easy to do on a *nix platform.

      It might be worth noting that this only works with binary (compiled) programs, but not with scripts. Reason is that the script interpreter would need to be able to read the source... In other words, if the app is in Perl, its source cannot be "hidden" using this technique.

[reply]

Back to Seekers of Perl Wisdom