[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS

From: KO Myung-Hun
Subject: Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2
Date: Wed, 18 Oct 2023 23:21:49 +0900
User-agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.6esrpre) Gecko/20120715 Firefox/10.0.6esrpre SeaMonkey/2.7.2


Zack Weinberg wrote:
> On Sun, Oct 15, 2023, at 3:43 AM, KO Myung-Hun wrote:
>> Zack Weinberg wrote:
>>> On Sat, Oct 14, 2023, at 9:19 AM, KO Myung-Hun wrote:
>>>> * bin/ (handle_output): Ignore setting mode failure on OS/2.
>>> Not OK, for two reasons:
> ...
>> How about this ?
>> 1. create and close a temporary file
>> 2. chmod() on it
>> 3. re-open it with O_TRUNC ?
> Multi-user security is probably not a concern for modern-day use of
> OS/2.  Also, the temporary files created by the code we’re talking
> about are not created in a system-wide scratch directory.  So we
> probably *could* do it this way, but I don’t like it, because it’s
> not safe in the general case.
> The trouble is, on a multi-user system, any time you do any operation
> by name on a file whose full pathname includes a world-writable
> directory (such as the system-wide scratch directories), even if that
> directory is “sticky” (chmod +t), you have to be exquisitely careful,
> or a malicious concurrent process might be able to trick you into
> overwriting some file elsewhere on the filesystem.  For example, your
> steps 2 and 3, if executed as root on a file expected to exist in
> /tmp, would give a malicious concurrent process a chance to clobber
> the access control bits and/or the contents of *any file*, by moving
> the temporary file out of the way, and replacing it with a symlink,
> in between steps 1 and 2.  That’s a narrow race window to hit, but
> it has been done successfully in the past.
> I don’t want to have code in Autoconf that is only safe because of
> non-obvious details of the context it’s used in.  People might
> reuse the code in a different context where it’s *not* safe, without
> realizing the danger.  So I suggest we use the appended patch
> instead of your patch.  I’ve tested this on Unix systems with both
> Perl 5.6 and Perl 5.38.  Could you please test it on your OS/2 system
> as well?

It works well here.


KO Myung-Hun

Korean OS/2 User Community :

reply via email to

[Prev in Thread] Current Thread [Next in Thread]