[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 |
Hi/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/autom4te.in (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.
Thanks!
--
KO Myung-Hun
Korean OS/2 User Community : https://www.os2.kr/
- [PATCH 0/2] OS/2 patches, KO Myung-Hun, 2023/10/14
- [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2, KO Myung-Hun, 2023/10/14
- Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2, Zack Weinberg, 2023/10/14
- Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2, KO Myung-Hun, 2023/10/15
- Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2, Zack Weinberg, 2023/10/17
- Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2, Paul Eggert, 2023/10/17
- Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2, Zack Weinberg, 2023/10/18
- Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2,
KO Myung-Hun <=
- Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2, Zack Weinberg, 2023/10/18
[PATCH 1/2] Fix detection of GNU M4 on mksh, KO Myung-Hun, 2023/10/14
- Re: [PATCH 1/2] Fix detection of GNU M4 on mksh, Zack Weinberg, 2023/10/14
- Re: [PATCH 1/2] Fix detection of GNU M4 on mksh, KO Myung-Hun, 2023/10/15
- Re: [PATCH 1/2] Fix detection of GNU M4 on mksh, Zack Weinberg, 2023/10/17
- Re: [PATCH 1/2] Fix detection of GNU M4 on mksh, KO Myung-Hun, 2023/10/18
- Re: [PATCH 1/2] Fix detection of GNU M4 on mksh, Zack Weinberg, 2023/10/18
- Re: [PATCH 1/2] Fix detection of GNU M4 on mksh, KO Myung-Hun, 2023/10/19