Create the repl history file with private permissions (as most tools are doing).
Tested on Linux, I don't know whether this works on non-POSIXy systems.
Afficher les réponses par date
Wouldn't it be better to create it with the current UMASK?
Brad
On Oct 14, 2008, at 6:53 PM, Christian Jaeger wrote:
Create the repl history file with private permissions (as most tools are doing).
Tested on Linux, I don't know whether this works on non-POSIXy systems.
diff -r 3137e9f51f48 lib/_repl.scm --- a/lib/_repl.scm Sun Sep 28 10:21:47 2008 -0400 +++ b/lib/_repl.scm Wed Oct 15 00:49:26 2008 +0200 @@ -2114,7 +2114,7 @@ (##display history port) (##close-port port)))) open-output-file
path-or-settings)))))))
(##cons permissions: (##cons #o600 path-or-
settings)))))))))
(let ((result (let ((input-port (macro-repl-channel-input-port
channel))) _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Bradley Lucier wrote:
Wouldn't it be better to create it with the current UMASK?
That was the previous behaviour, i.e. permissions: #o666.
Usually you're using an umask that allows read permission to other users, i.e. is used to describe how permissive writing to your files is. There's no separate umask for sensitive files. Programs wishing to make files private need to do so explicitely (examples that do so include bash, mysql, psql, rlwrap).
The "perlfunc" manpage says about umask:
«Here's some advice: supply a creation mode of 0666 for regular files (in "sysopen") and one of 0777 for directories (in "mkdir") and executable files. This gives users the freedom of choice: if they want protected files, they might choose process umasks of 022, 027, or even the particularly antisocial mask of 077. Programs should rarely if ever make policy decisions better left to the user. The exception to this is when writing files that should be kept private: mail files, web browser cookies, .rhosts files, and so on.»
(The libc manual says:
«Programs that create files typically specify a mode argument that includes all the permissions that make sense for the particular file. For an ordinary file, this is typically read and write permission for all classes of users. These permissions are then restricted as specified by the individual user's own file creation mask. »
Since history files could contain sensitive information, a permissive file mode like for normal files doesn't "make sense".)
Note that you could always "chmod" the file's permissions after it's creation to make it more accessible, Gambit won't change the permissions of the file once it exists. This is also a bit of a caveat to normal users: the given patch doesn't make your already existing history files (from previous Gambit versions) private, you need to make those private manually (or delete them).
Christian.