If you don't find exactly the solution you want, possible measures:
* If the concern is security, create the files in a directory on which you've set sufficiently restrictive permissions. (Even if you always set the file permissions immediately after opening the file for writing, there could be a race condition that lets the file be opened between create and permissions set.)
* If you are ruthless, you could set the umask for entire process, using the FFI for the system call.
* If you don't want to FFI, but you really-really want to second-guess the parent process's umask, you could kludge it in pure Racket plus host processes, at least on Unix-ish systems. Have the Racket program check its umask, and if not the desired one, use process/shell API to create a new process of the same Racket program, with the same command line, but under the new umask.
* Consider writing your own pure Racket convenience procedures for opening files with desired permissions. (Maybe you could even have it secretly do tricks to do the non-atomic create and chmod securely without messing with FFI or umask. Some tricks of moving and copying files might occasionally run afoul of unusual situations in the filesystem, and of finer points of different filesystem semantics, but in practice, most people will never encounter any problems with simple tricks.)
Side note: The Unix o/g/a-r/w/x permissions are pragmatic and archaic, so (like much of Unix) don't read too much into them, but they seem to have survived OK. And there seems to be less need for fancier ACLs and compartmentalization and such, now that we've moved most multi-user access control out of the filesystem and into Internet protocols and larger structures of same. And into VMs.
Neil V. ____________________ Racket Users list: http://lists.racket-lang.org/users
