Path: ...!weretis.net!feeder8.news.weretis.net!fu-berlin.de!uni-berlin.de!not-for-mail
From: 2QdxY4RzWzUUiLuE@potatochowder.com
Newsgroups: comp.lang.python
Subject: Re: shutil.rmtree() fails when used in Fedora (rpm) "mock" environment
Date: Thu, 24 Oct 2024 16:25:56 -0400
Lines: 39
Message-ID: <mailman.42.1729802816.4695.python-list@python.org>
References: <4a13731716200669342338ae409e73ca@posteo.de>
 <CAJQBtg=kCr0VMGXvkBcj4U6CwatC2_G2dstO5pS56_koAXJurA@mail.gmail.com>
 <0c080a7d-92de-4518-ac44-78d97fc9e3bb@mrabarnett.plus.com>
 <CAJQBtg=ButLwvoA2USBEV8-q=taRhuC+t6D1HkJMbG9VzTvxnQ@mail.gmail.com>
 <69934a74-6d04-40a0-a75f-b8024bd0af43@mrabarnett.plus.com>
 <CAJQBtgm6Re8tj5hKAZ7Zz6+NC-0iqcBH-MKo8gaOMm8A4prZfA@mail.gmail.com>
 <db1bf48a-01a8-4f7e-8d13-33da26af7613@mrabarnett.plus.com>
 <ZxqtVHjJOR8XZyHR@anomaly>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cancel-Lock: sha1:MxiwolSR4Itfb6kr84377gwgR2Y= sha256:FAEfglqV10y5c8Q5eYBRNSm6uRqz8CTxF+WS67Br+rE=
Mail-Followup-To: python-list@python.org
Content-Disposition: inline
In-Reply-To: <db1bf48a-01a8-4f7e-8d13-33da26af7613@mrabarnett.plus.com>
Precedence: list
Bytes: 6898

On 2024-10-24 at 20:54:53 +0100,
MRAB via Python-list <python-list@python.org> wrote:

> On 2024-10-24 20:21, Left Right wrote:
> > > > > The stack is created on line 760 with os.lstat and entries are appended
> > > > > on lines 677 (os.rmdir), 679 (os.close) and 689 (os.lstat).
> > > > >
> > > > > 'func' is popped off the stack on line 651 and check in the following lines.
> > > > >
> > > > > I can't see anywhere else where something else is put onto the stack or
> > > > > an entry is replaced.
> > 
> > But the _rmtree_safe_fd() compares func to a *dynamically* resolved
> > reference: os.lstat. If the reference to os changed (or os object was
> > modified to have new reference at lstat) between the time os.lstat was
> > added to the stack and the time of comparison, then comparison
> > would've failed.  To illustrate my idea:
> > 
> > os.lstat = lambda x: x # thread 1
> > stack.append((os.lstat, ...)) # thread 1
> > os.lstat = lambda x: x # thread 2
> > func, *_ = stack.pop() # thread 1
> > assert func is os.lstat # thread 1 (failure!)
> > 
> > The only question is: is it possible to modify os.lstat like that, and
> > if so, how?
> > 
> > Other alternatives include a malfunctioning "is" operator,
> > malfunctioning module cache... all those are a lot less likely.
> What is the probability of replacing os.lstat, os.close or os.rmdir from
> another thread at just the right time?

That is never the right question in a multi-threaded system.  The answer
is always that is doesn't matter, the odds will beat you in the end.  Or
sometimes right in the middle of a CPU instruction; does anyone remember
the MC680XX series?

Yes, as a matter of fact, I did used to make my living designing,
building, delivering, and maintaining such systems.