Re: world writeable files

["Colm Smyth [RU-Ireland]" <colms ireland sun com>]

So long as the temporary location is within the same directory, there
is less likelihood of a problem (either rename()ing across file-systems,
or due to permissions on the directory - /tmp is naturally more of an
isssue).

Colm.

>X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp redhat com 
using -f
>To: "Colm Smyth [RU-Ireland]" <Colm Smyth ireland sun com>
>Cc: Colm Smyth ireland sun com, drfickle k-lug com, gconf-list gnome org
>Subject: Re: world writeable files
>From: Havoc Pennington <hp redhat com>
>User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
>MIME-Version: 1.0
>
>
>"Colm Smyth [RU-Ireland]" <colms ireland sun com> writes:
>> I'd suggest removing the call to umask altogether; it's hard for apps
>> to do the right thing all the time, that's why it's generally set
>> from the shell.
>> 
>> If there's no way to tell xmlSaveFile() to use the "ambient" umask,
>> better pass the current value of umask(), obtained using something
>> like:
>> 
>> 	umask(cmask = umask(0)); /* cmask contains the current umask
>> 	*/
>
>xmlSaveFile() does use the ambient mask.
>
>Back in the mists of time, I was trying to provide some way to
>configure the permissions on files created by the XML backend, and the
>way it works is that it picks the permissions of the parent directory
>(minus search bit). So this wasn't being done for the files created by
>xmlSaveFile, the umask was used instead, and I had the umask(0) which
>was one of the first lines of code in gconfd, copied from Steven's
>daemon boilerplate in APUE. Result was 644 files. ;-) Oops.
>
>Anyhow, at the moment umask(022) is theoretically having no effect
>since the XML backend explicitly sets permissions, but you're probably
>right it should come out.
>
>There's a small race condition where we xmlSaveFile to a temporary
>file, then chmod() the file, then rename it to its final location; the
>umask gets used for the initial xmlSaveFile. An attacker could in
>principle get access to the pre-chmod() file before we get a chance to
>chmod() it. So that might be an argument for setting the umask to 066,
>if we're going to keep the idea of configuring perms from the parent
>directory. (i.e. we want to xmlSaveFile as completely private, and
>then move it to the perhaps more open permissions.)
>
>As a better solution, we could just write a util function
>xmlSaveFileWithPerms which temporarily changes the umask around the
>xmlSaveFile then puts it back, and calls chmod().
>
>Havoc
>
>