[fpc-pascal] Resource strings, passwords etc.

Tony Whyman tony.whyman at mccallumwhyman.com
Wed Jul 13 12:19:46 CEST 2016

What's interested me is how this thread has almost looped back to a 
recent thread on that steaming heap of brown stuff know as GTK and the 
attitude of the programmers behind it.

I had a similar problem a few years ago whiich I wanted to solve by 
putting the passwords in an external file and using file permissions to 
hide it from the bad guys. The file could be owned and only readable by 
root, or better some ordinary user. The preferred solution was to make 
it read/write a non-login user and read only to a group but no one else. 
Users had to be members of the group to read it. Better still was to 
make the program setgid to that group, allowing anyone who could run the 
program (and login into the database) to get access to the password 
controlled info without being able to actually read the password themselves.

However, GTK gets in the way of this because some bozo GTK developer 
thinks they should police use of setuid and setgid from GTK and will 
raise an exception if run from a setgid program. Google "gtk setgid" for 
examples. I can't see a security problem from setgid to a normal group - 
to me its a security mechanism, but you try telling that to the GTK team.

Read http://www.gtk.org/setuid.html for an example of some incredibly 
muddled thinking. They make the point here that GTK is (too) complex and 
difficult to analyse hence setuid (and setgid) is bad on the grounds 
that no one knows how it could be mis-used. They then recommend writing 
an setuid backend in such situations, without recognising that all they 
have done is to move a problem rather than solve it. I wanted my program 
to be setgid so that only it could access privileged information. If I 
write a setgid backend program now I have to find a way of 
authenticating my GTK frontend to my backend.... (Oh perhaps I should 
have an embedded password).

The point is that while it is reasonable for a developer to give 
guidance on what is good practice, actively stopping a user from using 
your code in a way that you do not approve is not just stupid and 
contemptuous of your users, it can actually get in the way of the right 
solution to a problem that you do not know about.

Assuming that this problem still exists in GTK2, it may get in the way 
of what otherwise could be a good way to solve the original problem in 
this thread.


On 13/07/16 08:31, Mark Morgan Lloyd wrote:
> Michael Van Canneyt wrote:
>> On Tue, 12 Jul 2016, Mark Morgan Lloyd wrote:
>>> Please excuse one of my regular silly questions. Elsewhere, a 
>>> (former) Delphi programmer is uneasy having found that his binaries 
>>> have had embedded SQL queries, passwords and so on visible "in 
>>> clear" for the last 20 years or so.
>>> Can FPC be told to obfuscate ResourceStrings?
>> No. The default value for resourcestrings is stored as-is in the binary.
>> To solve this, I store the username/password encrypted in the binary 
>> as consts, and they are decrypted when needed.
> Sometimes it's difficult to avoid having to do that sort of thing, or 
> obfuscating them in an external file.

More information about the fpc-pascal mailing list