I wrote this in C once to try it out. I have the source code at work which I can send you if you're interested. I don't think all the functions I used have been implemented in the Win32 modules.

For some time I have wanted to write a module which would perform this kind of automatically-authenticated IPC connection, with variants for different OSes. On some *nix systems there is a SO_PEERCRED socket option to identify a local connection. You can also use a convoluted protocol where the client proves his identity by performing some actions in the file system. But, alas, I haven't gotten around to doing it.

This style of programming is somewhat more secure than setuid or sudo. E.g. it's less susceptible to manipulation of environment variables. Also, with setuid programs, if you want to use a cryptographic key you have to store it in the file system and hope that file system security and obfuscation protect it. With the authenticated-IPC style, the (trusted) person who starts the process can type in a password once and the key can be kept in memory.

Some more Google shows that these are Windows API functions, so you could just write a small XS or Inline::C module that does the trick. That is, if the functions are suitable for you.

It's not hard, really. I was scared when I did my first XS module to wrap an API function with the least overhead possible, but it was quite easy, given the loads of documentation out there.</>

Unfortunately, the documentation says that any process using LoginAsUser nees "act as part of the operating system" (SeTcbPrivilege). I'm not sure it is wise to grant that priv to all users.

--traveler

Can't you just put all the people who need access, into one group and give that group read/write access?

Yse, but then anyone in the group could mangle the file. Also, virtually all users on the system need access. The file entries are scores. Individuals may want to adjust their or other users' scores for whatever reason. There is not a lot of trust between these users...

--traveler

OK sorry, my bad for not reading your original post closely enough.

One 'round the houses' approach would be to use IIS. Start by configuring IIS to disable anonymous access and enable 'Basic Authentication'. Then have your script access a CGI script using LWP and supplying a username/password, eg:

  my $ua = LWP::UserAgent->new()

  my $request = HTTP::Request->new(GET => $cgi_url);

  $request->authorization_basic($username, $password);

  my $response = $ua->request($request);
[download]

When the script pointed to by $cgi_url is run, IIS will have arranged for it to be running under the security context of user $username. Furthermore, the security token which results from this type of authentication would allow the CGI process to access files on remote shares - handy if you don't have IIS on the box where the high socre file lives. The URL you requested would presumably include a querystring containing any new data to be written to the file.

Of course the major drawback of this approach is that the username and password must be available in clear text to your script which means that one of your users could subvert the system if they had access to the source and were determined enough.

I cannot do that (but would like to). My question is still, how do I keep from having to have the db (MySQL, flat file, etc) be world writable?

--john

I cannot do that (but would like to). My question is still, how do I keep from having to have the db (MySQL, flat file, etc) be world writable?

The DB files could be protected so that only the user that the service runs as has write permission. But easier is to set the DB service to start automatically, which means it will start as soon as the machine boots. Which would be before any user can authenticate themselves. The DB would then obtain a lock on the DB file, and since Win32 provides compulsory locking semantics and not advisory locking semantics the files would be effectively locked to anyone other than the DB service.

Overall there are a number of ways to accomplish what you want. But they wont be the *nix ways, so you might have to look at a different approach. For instance I think you prematurely dismissed (and for reasons that I dont think were correct) the service based approach suggested earlier.

---
demerphq