On Feb 3, 2010, at 6:43 PM, Earl Hood wrote:
> On Wed, Feb 3, 2010 at 8:06 PM, Chad Brown wrote:
>> I don't know that anyone cares, but POSIX says ``TMPDIR'':
>
> Recent commit uses the following, in order:
>
> *MHTMPDIR envvar
> *TMPDIR envvar
> *TMP envvar
> *User's mail direc
On Wed, Feb 3, 2010 at 8:06 PM, Chad Brown wrote:
> I don't know that anyone cares, but POSIX says ``TMPDIR'':
Recent commit uses the following, in order:
*MHTMPDIR envvar
*TMPDIR envvar
*TMP envvar
*User's mail directory.
--ewh
On Wed, Feb 3, 2010 at 5:59 PM, Sean Kamath wrote:
> My real point was that it should be configurable, which you've done.
> Slightly odd to make it an env variable than an nmh setting in
> .mh_profile, but whatever.
I don't know that anyone cares, but POSIX says ``TMPDIR'':
http://www.opengro
On Wed, Feb 3, 2010 at 5:59 PM, Sean Kamath wrote:
> My real point was that it should be configurable, which you've done.
> Slightly odd to make it an env variable than an nmh setting in
> .mh_profile, but whatever.
It's easy to add .mh_profile check, but not all
commands read the profile (e.g. po
Earl Hood wrote:
> On Wed, Feb 3, 2010 at 12:20 PM, Sean Kamath wrote:
>
>> Frankly, people who run tmp cleaners that are that braindead probably
>> deserve what they get.
>
> Are we to worry about braindead temp cleaners? I.e. I'm
> sure other apps would have problems with braindead
> cleaners,
Earl Hood wrote:
>On February 3, 2010 at 15:23, valdis.kletni...@vt.edu wrote:
>
>> Given that the vast majority of nmh users are probably on laptops or
>> single-user desktop boxes rather than large central servers with untrusted
>> other users on them, and your code *is* an improvement, I think t
On February 3, 2010 at 15:23, valdis.kletni...@vt.edu wrote:
> Given that the vast majority of nmh users are probably on laptops or
> single-user desktop boxes rather than large central servers with untrusted
> other users on them, and your code *is* an improvement, I think the best
> thing to do
On Wed, 03 Feb 2010 13:56:40 CST, Earl Hood said:
> A descision to be made is the work I have currently
> done worth rejecting because it fails to address all
> (less probable) cases, or accept it now for something
> better than what currently exists and then improve
> upon it later?
Given that t
On Wed, Feb 3, 2010 at 12:30 PM, wrote:
>> If the calling code did not immediately use the temp file,
>> the new functions close the descriptor returned from mkstemp(),
>> but it does NOT delete the file.
>>
>> Since the file still exists, an external (different uid) process
>> cannot create one
On Wed, Feb 3, 2010 at 12:20 PM, Sean Kamath wrote:
> Frankly, people who run tmp cleaners that are that braindead probably
> deserve what they get.
Are we to worry about braindead temp cleaners? I.e. I'm
sure other apps would have problems with braindead
cleaners, so should we waste resources d
On Tue, 02 Feb 2010 21:38:20 CST, Earl Hood said:
> If the calling code did not immediately use the temp file,
> the new functions close the descriptor returned from mkstemp(),
> but it does NOT delete the file.
>
> Since the file still exists, an external (different uid) process
> cannot create
Earl Hood wrote:
> On Wed, Feb 3, 2010 at 2:58 AM, Peter Maydell
> wrote:
>> Earl Hood wrote:
>>> Even though no one has convinced me that my new functions
>>> still contain the race condition security problem,
>> There was a URL in the old linked message I provided;
>> the problem is in the prese
On Wed, Feb 3, 2010 at 2:58 AM, Peter Maydell
wrote:
> Earl Hood wrote:
>>Even though no one has convinced me that my new functions
>>still contain the race condition security problem,
>
> There was a URL in the old linked message I provided;
> the problem is in the presence of /tmp/ cleaners (whi
Earl Hood wrote:
>Even though no one has convinced me that my new functions
>still contain the race condition security problem,
There was a URL in the old linked message I provided;
the problem is in the presence of /tmp/ cleaners (which,
yes, do exist even if there are problems with them).
I'll
Even though no one has convinced me that my new functions
still contain the race condition security problem,
I've updated the new functions to default to using the
user's mail directory for creating temp file if no
template is provided.
New version of m_mktemp.c is attached. None of the
changes I
On February 2, 2010 at 13:40, Earl Hood wrote:
> Attached are the changes I have currently done in my development
> environment. The changes also include minor mods to deal
> with "may be uninitialized" warnings from gcc.
Found a problem with mhparse.c with the changes I did. Temporary files
ca
The changes I've made do not contain the same security flaw
that has been noted, from what I understand.
The old, insecure, mktemp() does NOT create a file. All
it does is provide a temporary filename, that (at-the-time)
does not exist. Therefore, when using it, there is a
race condition between
17 matches
Mail list logo
