On Wed, 29 May 2024 17:20:08 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

> John Ames <commodorejohn@gmail.com> writes:
> > Minimal-assistance-in-the-absence-of-direct-supervision is a *very*
> > different thing from intelligent-override-of-deliberate-action.
>
> I think some automated braking for goalposts is needed here.

Let me come back at my point, then: security precautions predicated on
the assumption that an Authorized Person is not operating in good faith
and due diligence concordant with their level of authorization suffer
from severe diminishing returns with each additional layer of safeguard
and may even reach a point where they're *counterproductive.*

Restricting the ability to install software to a designated group of
administrators, f'rexample, is a perfectly sensible thing to do,
especially in a large shared system. But once you've created such a
group, assessing whether a given individual is trustworthy and
knowledgeable enough to be a member of it is an organizational problem,
*not* a technical one.

Some measure of safeguarding may still be worth the bother despite this
(while Windows's "hey, you got this thing off the Interwebs, you sure
'sokay?" prompts annoy me personally, I can see the logic behind them,)
but every additional layer calls further into question what the point
of even having the group is in the first place, and whether *anyone*
should really be a member of it. If not, why did you let them in? If
so, why are you hampering their ability to exercise that authority?

This has become semi-famously an issue in medical software, for
instance. Developers of some major EMR systems, driven by regulatory
and legal CYA concerns, have put so many are-you-sure and please-
acknowledge-XYZ prompts into their core workflow that doctors (who are,
shockingly, only human) end up clicking through them machine-gun style,
and pay *less* attention to the actually critical stuff than they
would've if it weren't buried in an avalanche of white noise.

And doctors aren't software specialists; sysadmins *are.* Throw too
many safeguards in the path of a sysadmin just trying to get shit done,
and you don't end up with a sysadmin forced to question whether they
really *are* sure, or even a sysadmin powering doctor-style through a
set of nagging little obstacles they aren't thinking about; you end up
with a sysadmin who will - guaranteed - develop a process of *disabling
the entire safeguard system* for the duration of the job, and then (if
you're lucky) re-enabling it afterward.

We saw exactly that with UAC in Windows Vista; it was so bad that the #1
method for dealing with it was to disable it entirely, and people were
so burned by it that that remained true *well* into the Win10 era,
despite MS's attempts to temper it into some measure of reasonability.

So no, I don't think that a couple examples of minimal assistance in
situations where direct supervision is either absent or impaired *do*
constitute a hard-and-fast argument against temperance in security
design as a general principle. Sometimes a little extra safety is worth
it, sometimes not; and sometimes you're actually shooting yourself in
the foot.

And if I had to place my bets on where changing the behavior of
fundamental system calls in a major OS family where they've been
standard since the '70s lies on that spectrum...well, it's not gonna be
in the "worth it" zone.

Muttley@dastardlyhq.com writes:
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>Muttley@dastardlyhq.com, dans le message <v36kd8$11r1b$1@dont-email.me>,
>>>> a écrit :
>>>>> The simple answer being that no process uses /tmp unless it needs to share
>>>>> data with another via files.
>>>>
>>>>So where should they put their temporary files?
>>>
>>> $ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
>>>
>>> Note that /tmp and /var/tmp usually have the "Sticky" mode bit
>>> set which limits the operations that a non-owner can
>>> perform on a file in that directory.
>>
>>This solves only half of the problem: mkdir will fail if the given
>>filesystem name already exists. Some scheme to create unguessable names
>>and try using them until success would still be needed on top of that.
>
> Process id + time and date down to the microsecond in the filename usually
> solves that problem. If multi threaded then throw in the thread id too.
> Creating unique filenames isn't a problem so long as everyone sticks to the
> scheme.

BASE64-encoding a random number would also work. But I didn't claim this
would be particularly complicated, just that it needed to be done.

Muttley@dastardlyhq.com, dans le message <v37no9$17tpi$1@dont-email.me>,
a écrit :
> Create a dot directory in the users home dir

So you suggest to use for temporary files a place where space might be
limited, and/or slow, and/or with expensive writes?

That's rather bad design.

Rainer Weikusat <rweikusat@talktalk.net> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>Muttley@dastardlyhq.com, dans le message <v36kd8$11r1b$1@dont-email.me>,
>>> a écrit :
>>>> The simple answer being that no process uses /tmp unless it needs to share
>>>> data with another via files.
>>>
>>>So where should they put their temporary files?
>>
>> $ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
>>
>> Note that /tmp and /var/tmp usually have the "Sticky" mode bit
>> set which limits the operations that a non-owner can
>> perform on a file in that directory.
>
> This solves only half of the problem: mkdir will fail if the given
> filesystem name already exists. Some scheme to create unguessable names
> and try using them until success would still be needed on top of that.

`mkdir -p` solves that part of the problem. But what if somebody else
has created a directory whose name happens to match your ${LOGNAME}?
It's a convention that works only if everyone follows it.

As Scott Lurndal points out, this is what mktemp(1) is for.

Also, I don't have $TMPDIR in my environment.

(As for $LOGNAME, I usually use $USER, but I see that POSIX only
specifies $LOGNAME so that's probably safer.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>Muttley@dastardlyhq.com, dans le message <v36kd8$11r1b$1@dont-email.me>,
>>>> a écrit :
>>>>> The simple answer being that no process uses /tmp unless it needs to share
>>>>> data with another via files.
>>>>
>>>>So where should they put their temporary files?
>>>
>>> $ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
>>>
>>> Note that /tmp and /var/tmp usually have the "Sticky" mode bit
>>> set which limits the operations that a non-owner can
>>> perform on a file in that directory.
>>
>> This solves only half of the problem: mkdir will fail if the given
>> filesystem name already exists. Some scheme to create unguessable names
>> and try using them until success would still be needed on top of that.
>
> `mkdir -p` solves that part of the problem.

That's not a problem. It's an important featue of a partial solution.

> But what if somebody else
> has created a directory whose name happens to match your ${LOGNAME}?
> It's a convention that works only if everyone follows it.
>
> As Scott Lurndal points out, this is what mktemp(1) is for.

Or mkstemp or tmpfile. On Linux (since 3.11), there's also an O_TMPFILE
open flag which creates a namless open file in some directory (passed as
pathname argument to open). It's also not really complicated to do this
with plain open:

1. Generate a 'hard to guess' name
2. Try opening with O_CREAT | O_EXCL
3. Success? => return fd
4. goto 1

Rainer Weikusat <rweikusat@talktalk.net> writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>>Muttley@dastardlyhq.com, dans le message <v36kd8$11r1b$1@dont-email.me>,
>>>>> a écrit :
>>>>>> The simple answer being that no process uses /tmp unless it needs to share
>>>>>> data with another via files.
>>>>>
>>>>>So where should they put their temporary files?
>>>>
>>>> $ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
>>>>
>>>> Note that /tmp and /var/tmp usually have the "Sticky" mode bit
>>>> set which limits the operations that a non-owner can
>>>> perform on a file in that directory.
>>>
>>> This solves only half of the problem: mkdir will fail if the given
>>> filesystem name already exists. Some scheme to create unguessable names
>>> and try using them until success would still be needed on top of that.
>>
>> `mkdir -p` solves that part of the problem.
>
>That's not a problem. It's an important featue of a partial solution.
>
>> But what if somebody else
>> has created a directory whose name happens to match your ${LOGNAME}?
>> It's a convention that works only if everyone follows it.
>>
>> As Scott Lurndal points out, this is what mktemp(1) is for.
>
>Or mkstemp or tmpfile. On Linux (since 3.11), there's also an O_TMPFILE
>open flag which creates a namless open file in some directory (passed as
>pathname argument to open). It's also not really complicated to do this
>with plain open:
>
>1. Generate a 'hard to guess' name
>2. Try opening with O_CREAT | O_EXCL
>3. Success? => return fd
>4. goto 1

0. Use the mkdirat(2) system call rather than mkdir(2) when
creating the subdirectory in ${TMPDIR:-/tmp}. It may
be that the library functions backing mktemp et al already do
this...

On Wed, 29 May 2024 21:42:47 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>Muttley@dastardlyhq.com writes:
>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>>Muttley@dastardlyhq.com, dans le message <v36kd8$11r1b$1@dont-email.me>,
>>>>> a écrit :
>>>>>> The simple answer being that no process uses /tmp unless it needs to
>share
>>>>>> data with another via files.
>>>>>
>>>>>So where should they put their temporary files?
>>>>
>>>> $ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
>>>>
>>>> Note that /tmp and /var/tmp usually have the "Sticky" mode bit
>>>> set which limits the operations that a non-owner can
>>>> perform on a file in that directory.
>>>
>>>This solves only half of the problem: mkdir will fail if the given
>>>filesystem name already exists. Some scheme to create unguessable names
>>>and try using them until success would still be needed on top of that.
>>
>> Process id + time and date down to the microsecond in the filename usually
>> solves that problem. If multi threaded then throw in the thread id too.
>> Creating unique filenames isn't a problem so long as everyone sticks to the
>> scheme.
>
>BASE64-encoding a random number would also work. But I didn't claim this
>would be particularly complicated, just that it needed to be done.

Always the danger of a collision if both programs seeded the sequence with
the same value, albeit very small.

On 29 May 2024 21:48:57 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>Muttley@dastardlyhq.com, dans le message <v37no9$17tpi$1@dont-email.me>,
> a �crit�:
>> Create a dot directory in the users home dir
>
>So you suggest to use for temporary files a place where space might be
>limited, and/or slow, and/or with expensive writes?
>
>That's rather bad design.

You conveniently snipped the bit where I mentioned quotas. However you might
want to take a look in your home directory at all the . files (and some not)
and look at what various desktop apps dump there. Eg Various browsers save
megabytes of cache data.

On Fri, 31 May 2024 07:27:53 -0000 (UTC)
Muttley@dastardlyhq.com wrote:
>On 29 May 2024 21:48:57 GMT
>Nicolas George <nicolas$george@salle-s.org> wrote:
>>Muttley@dastardlyhq.com, dans le message <v37no9$17tpi$1@dont-email.me>,
>> a �crit�:
>>> Create a dot directory in the users home dir
>>
>>So you suggest to use for temporary files a place where space might be
>>limited, and/or slow, and/or with expensive writes?
>>
>>That's rather bad design.
>
>You conveniently snipped the bit where I mentioned quotas. However you might
>want to take a look in your home directory at all the . files (and some not)
>and look at what various desktop apps dump there. Eg Various browsers save
>megabytes of cache data.
>

I meant . directories obv.

Muttley@dastardlyhq.com, dans le message <v3bu5o$24p7r$1@dont-email.me>,
a écrit :
> You conveniently snipped the bit where I mentioned quotas.

Indeed: it did not make your suggestion better.

On 31 May 2024 08:59:37 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>Muttley@dastardlyhq.com, dans le message <v3bu5o$24p7r$1@dont-email.me>,
> a �crit�:
>> You conveniently snipped the bit where I mentioned quotas.
>
>Indeed: it did not make your suggestion better.

My suggestion is how a lot of modern applications work whether you like it or
not.

Muttley@dastardlyhq.com, dans le message <v3cafb$26qfs$1@dont-email.me>,
a écrit :
> My suggestion is how a lot of modern applications work

Not the endorsement you think it is.

Muttley@dastardlyhq.com writes:
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>Muttley@dastardlyhq.com writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>>>Muttley@dastardlyhq.com, dans le message <v36kd8$11r1b$1@dont-email.me>,
>>>>>> a écrit :
>>>>>>> The simple answer being that no process uses /tmp unless it needs to
>>share
>>>>>>> data with another via files.
>>>>>>
>>>>>>So where should they put their temporary files?
>>>>>
>>>>> $ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
>>>>>
>>>>> Note that /tmp and /var/tmp usually have the "Sticky" mode bit
>>>>> set which limits the operations that a non-owner can
>>>>> perform on a file in that directory.
>>>>
>>>>This solves only half of the problem: mkdir will fail if the given
>>>>filesystem name already exists. Some scheme to create unguessable names
>>>>and try using them until success would still be needed on top of that.
>>>
>>> Process id + time and date down to the microsecond in the filename usually
>>> solves that problem. If multi threaded then throw in the thread id too.
>>> Creating unique filenames isn't a problem so long as everyone sticks to the
>>> scheme.
>>
>>BASE64-encoding a random number would also work. But I didn't claim this
>>would be particularly complicated, just that it needed to be done.
>
> Always the danger of a collision if both programs seeded the sequence with
> the same value, albeit very small.

Regardless of the scheme that's employed, there's always a danger of
collisions, ie, of some other processing having created a file with this
name first.

On Fri, 31 May 2024 15:23:35 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>Muttley@dastardlyhq.com writes:
>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>Muttley@dastardlyhq.com writes:
>>>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>>>>Muttley@dastardlyhq.com, dans le message <v36kd8$11r1b$1@dont-email.me>,
>>>>>>> a écrit :
>>>>>>>> The simple answer being that no process uses /tmp unless it needs to
>>>share
>>>>>>>> data with another via files.
>>>>>>>
>>>>>>>So where should they put their temporary files?
>>>>>>
>>>>>> $ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
>>>>>>
>>>>>> Note that /tmp and /var/tmp usually have the "Sticky" mode bit
>>>>>> set which limits the operations that a non-owner can
>>>>>> perform on a file in that directory.
>>>>>
>>>>>This solves only half of the problem: mkdir will fail if the given
>>>>>filesystem name already exists. Some scheme to create unguessable names
>>>>>and try using them until success would still be needed on top of that.
>>>>
>>>> Process id + time and date down to the microsecond in the filename usually
>
>>>> solves that problem. If multi threaded then throw in the thread id too.
>>>> Creating unique filenames isn't a problem so long as everyone sticks to the
>
>>>> scheme.
>>>
>>>BASE64-encoding a random number would also work. But I didn't claim this
>>>would be particularly complicated, just that it needed to be done.
>>
>> Always the danger of a collision if both programs seeded the sequence with
>> the same value, albeit very small.
>
>Regardless of the scheme that's employed, there's always a danger of
>collisions, ie, of some other processing having created a file with this
>name first.

After a program has exited it has no claim to any temporary files so thats
a non issue.

On 31 May 2024 13:15:52 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:

> Muttley@dastardlyhq.com, dans le message
> <v3cafb$26qfs$1@dont-email.me>, a écrit :
> > My suggestion is how a lot of modern applications work
>
> Not the endorsement you think it is.

Also not as true as all that, to begin with. While e.g. Chrome does
dump an irritating amount of junk in one's home directory, it's stuff
that has at least some reason for being persistent; it still uses /tmp
for genuinely transient stuff. Can attest, just had an errant program
fill up /tmp on me the other day, and Chromium wouldn't open 'til I
cleared it.

Muttley@dastardlyhq.com writes:
> On Fri, 31 May 2024 15:23:35 +0100
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>Muttley@dastardlyhq.com writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>Muttley@dastardlyhq.com writes:
>>>>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>> Nicolas George <nicolas$george@salle-s.org> writes:
>>>>>>>>Muttley@dastardlyhq.com, dans le message <v36kd8$11r1b$1@dont-email.me>,
>>>>>>>> a écrit :
>>>>>>>>> The simple answer being that no process uses /tmp unless it needs to
>>>>share
>>>>>>>>> data with another via files.
>>>>>>>>
>>>>>>>>So where should they put their temporary files?
>>>>>>>
>>>>>>> $ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
>>>>>>>
>>>>>>> Note that /tmp and /var/tmp usually have the "Sticky" mode bit
>>>>>>> set which limits the operations that a non-owner can
>>>>>>> perform on a file in that directory.
>>>>>>
>>>>>>This solves only half of the problem: mkdir will fail if the given
>>>>>>filesystem name already exists. Some scheme to create unguessable names
>>>>>>and try using them until success would still be needed on top of that.
>>>>>
>>>>> Process id + time and date down to the microsecond in the filename usually
>>
>>>>> solves that problem. If multi threaded then throw in the thread id too.
>>>>> Creating unique filenames isn't a problem so long as everyone sticks to the
>>
>>>>> scheme.
>>>>
>>>>BASE64-encoding a random number would also work. But I didn't claim this
>>>>would be particularly complicated, just that it needed to be done.
>>>
>>> Always the danger of a collision if both programs seeded the sequence with
>>> the same value, albeit very small.
>>
>>Regardless of the scheme that's employed, there's always a danger of
>>collisions, ie, of some other processing having created a file with this
>>name first.
>
> After a program has exited it has no claim to any temporary files so thats
> a non issue.

It's an issue because a program may intentionally create files (or
symlinks) with names another program will likely try to use for a
temporary file in the near future. The same may happen for less
nefarious reasons because "shit happened", which it's wont to do.

In the general case, programs creating files in world-writable
directories need to handle the situation that another program might try
to use the same filename at the same time.

John Ames <commodorejohn@gmail.com> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> John Ames <commodorejohn@gmail.com> writes:
>>> Minimal-assistance-in-the-absence-of-direct-supervision is a *very*
>>> different thing from intelligent-override-of-deliberate-action.
>>
>> I think some automated braking for goalposts is needed here.
>
> Let me come back at my point, then: security precautions predicated on
> the assumption that an Authorized Person is not operating in good faith
> and due diligence concordant with their level of authorization suffer
> from severe diminishing returns with each additional layer of safeguard
> and may even reach a point where they're *counterproductive.*

They might. But, also, any assumption that people are always going to
(1) know how to correctly use the system in front of them and (2) get
all the details right every time, is going to be violated from time to
time.

I think it’s worth introducing systematic mitigations for those risks,
if that can be done without undue impact.

> Restricting the ability to install software to a designated group of
> administrators, f'rexample, is a perfectly sensible thing to do,
> especially in a large shared system.

Agreed.

> But once you've created such a group, assessing whether a given
> individual is trustworthy and knowledgeable enough to be a member of
> it is an organizational problem, *not* a technical one.

Agreed that the assessment is an organizational problem. But I’d hope
you’d agree that:

1) Even the best-run organization will get it wrong from time to time.
2) Not every organiation is particularly well run.
3) Trustworthy, knowledgeable individuals still make mistakes.

> Some measure of safeguarding may still be worth the bother despite this
> (while Windows's "hey, you got this thing off the Interwebs, you sure
> 'sokay?" prompts annoy me personally, I can see the logic behind them,)
> but every additional layer calls further into question what the point
> of even having the group is in the first place, and whether *anyone*
> should really be a member of it. If not, why did you let them in? If
> so, why are you hampering their ability to exercise that authority?
>
> This has become semi-famously an issue in medical software, for
> instance. Developers of some major EMR systems, driven by regulatory
> and legal CYA concerns, have put so many are-you-sure and please-
> acknowledge-XYZ prompts into their core workflow that doctors (who are,
> shockingly, only human) end up clicking through them machine-gun style,
> and pay *less* attention to the actually critical stuff than they
> would've if it weren't buried in an avalanche of white noise.

Agreed that excessive are-you-sure prompts have a high risk of training
their users to blindly click through.

But in the case of protected_regular there’s nothing to click through
and for the most part no-one ever notices any difference unless under
attack[1], so I don’t think that the are-you-sure prompts are a good
comparator.

[1] and in the few niche cases where someone does, they can think about
the tradeoffs and either disable it or work around it.

> And doctors aren't software specialists; sysadmins *are.* Throw too
> many safeguards in the path of a sysadmin just trying to get shit done,
> and you don't end up with a sysadmin forced to question whether they
> really *are* sure, or even a sysadmin powering doctor-style through a
> set of nagging little obstacles they aren't thinking about; you end up
> with a sysadmin who will - guaranteed - develop a process of *disabling
> the entire safeguard system* for the duration of the job, and then (if
> you're lucky) re-enabling it afterward.
>
> We saw exactly that with UAC in Windows Vista; it was so bad that the #1
> method for dealing with it was to disable it entirely, and people were
> so burned by it that that remained true *well* into the Win10 era,
> despite MS's attempts to temper it into some measure of reasonability.
>
> So no, I don't think that a couple examples of minimal assistance in
> situations where direct supervision is either absent or impaired *do*
> constitute a hard-and-fast argument against temperance in security
> design as a general principle. Sometimes a little extra safety is worth
> it, sometimes not; and sometimes you're actually shooting yourself in
> the foot.

I think collision assist is really good model for protected_regular.

The potential collision might be due to the driver’s occasional
inattention (analogy: sysadmin writes scripts most days, but mis-handles
filename spoofing risks occasionally) or it might be someone else’s
error (analogy: insecure download+install script).

The collision assist doesn’t prevent normal driving, it only activates
when things are about to go seriously wrong[2]; for almost everybody the
same is true of protected_regular, it only blocks anything when an
attack is underway.

[2] It may impede crash testing, but presumably if you’re doing that
you’re a manufacturer or evaluator and have the tools to disable it.

--
https://www.greenend.org.uk/rjk/

On Fri, 31 May 2024 22:18:16 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>Muttley@dastardlyhq.com writes:
>> After a program has exited it has no claim to any temporary files so thats
>> a non issue.
>
>It's an issue because a program may intentionally create files (or
>symlinks) with names another program will likely try to use for a
>temporary file in the near future. The same may happen for less
>nefarious reasons because "shit happened", which it's wont to do.

Why would a program try to use some random shit in a file instead of deleting
the file first or simply opening it with "w" in fopen() or O_TRUNC ?

>In the general case, programs creating files in world-writable
>directories need to handle the situation that another program might try
>to use the same filename at the same time.

Which is why you give your file a unique name. However there is no 100%
fullproof solution to this issue so if you're worried about it don't write
to a world writable directory.

Richard Kettlewell <invalid@invalid.invalid> writes:

[...]

> I think collision assist is really good model for protected_regular.
>
> The potential collision might be due to the driver’s occasional
> inattention (analogy: sysadmin writes scripts most days, but mis-handles
> filename spoofing risks occasionally) or it might be someone else’s
> error (analogy: insecure download+install script).
>
> The collision assist doesn’t prevent normal driving, it only activates
> when things are about to go seriously wrong[2]; for almost everybody the
> same is true of protected_regular, it only blocks anything when an
> attack is underway.

protected_regular does prevent "normal driving" and it decidedly
'activates' in situations where nothing untoward is underway. I've
described an example of that.

In absence of a specific example (I've asked for but didn't receive a
reply), I also don't think that 'protection' against random stuff Google
employees can dream up is a great asset.

Rainer Weikusat <rweikusat@talktalk.net> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> I think collision assist is really good model for protected_regular.
>>
>> The potential collision might be due to the driver’s occasional
>> inattention (analogy: sysadmin writes scripts most days, but mis-handles
>> filename spoofing risks occasionally) or it might be someone else’s
>> error (analogy: insecure download+install script).
>>
>> The collision assist doesn’t prevent normal driving, it only activates
>> when things are about to go seriously wrong[2]; for almost everybody the
>> same is true of protected_regular, it only blocks anything when an
>> attack is underway.
>
> protected_regular does prevent "normal driving" and it decidedly
> 'activates' in situations where nothing untoward is underway. I've
> described an example of that.

You’re not in the “almost everybody”.

--
https://www.greenend.org.uk/rjk/

Richard Kettlewell <invalid@invalid.invalid> writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>> I think collision assist is really good model for protected_regular.
>>>
>>> The potential collision might be due to the driver’s occasional
>>> inattention (analogy: sysadmin writes scripts most days, but mis-handles
>>> filename spoofing risks occasionally) or it might be someone else’s
>>> error (analogy: insecure download+install script).
>>>
>>> The collision assist doesn’t prevent normal driving, it only activates
>>> when things are about to go seriously wrong[2]; for almost everybody the
>>> same is true of protected_regular, it only blocks anything when an
>>> attack is underway.
>>
>> protected_regular does prevent "normal driving" and it decidedly
>> 'activates' in situations where nothing untoward is underway. I've
>> described an example of that.
>
> You’re not in the “almost everybody”.

There's nothing special about the technical situation I described. It's
reallyv completely everyday "best pratice" stuff: Run stuff as
unprivileged user where possible, use standard file system features to
limit access rights to anything to the necessary minimum.

Muttley@dastardlyhq.com writes:
> On Fri, 31 May 2024 22:18:16 +0100
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>Muttley@dastardlyhq.com writes:

[...]

>>In the general case, programs creating files in world-writable
>>directories need to handle the situation that another program might try
>>to use the same filename at the same time.
>
> Which is why you give your file a unique name. However there is no 100%
> fullproof solution to this issue so if you're worried about it don't write
> to a world writable directory.

There is no way to give files names which are guaranteed to be unique
unless the set of all program ever running on a given system and they
they're going to use the file system is known. And that's still just for
the ordinary case, ie, without hostile third parties trying to 'exploit'
something.

On Sat, 01 Jun 2024 18:50:58 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

> You’re not in the “almost everybody”.

He's also no true Scotsman.