or "Maybe, I'm full of it BUT I work for Google ... !"

I have program for executing another program with some fnctl-based file
locks held I've been using for almost 20 years. This program always
opens files with O_CREAT added to the mode so that, in case of multiple
concurrent calls of it and no previously existing file, one of these
calls creates the file and all others open it.

Further, I have a directory with the following permissions:

drwxrwx--T 6 root caca 4096 May 23 20:22 ca-CA/

as I want members of the caca group to be able to create files in this
directory but not remove files owned by root. Inside this directory,
there's a file with the following permissions:

-rw-r--r-- 1 caca caca 3 Jan 1 1970 serial

A shell script associated with that tries to acquire an R/W lock on this
file in order to serialize concurrent invocations of it. On Debian 12,
when running as root, this fails with EACCES. That's do to a suckurity
feature (supposed to make the system suck harder) documented as follows (proc(5)):

/proc/sys/fs/protected_regular (since Linux 4.19)

1 Don't allow O_CREAT open(2) on regular files that the caller doesn't
own in world-writable sticky directories, unless the regular file is
owned by the owner of the directory.

2 As for the value 1, but the restriction also applies to
group-writable sticky directories.

The intent of the above protections is similar to protected_fifos, but
allows an application to avoid writes to an attacker-controlled regular
file, where the application expected to create one.

and default value of this control knob is - for maxium suckurity because
Google says that's how it must be done and Google CANNOT be wrong!!! -
obviously 2.
 Who told this hyperintelligent being that O_CREAT means "application
expected to create a file" AND NOT "create file if it doesn't exist
already", ie, the documented semantics?

GRRRR.

On 2024-05-23, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> /proc/sys/fs/protected_regular (since Linux 4.19)
>
> 1 Don't allow O_CREAT open(2) on regular files that the caller doesn't
> own in world-writable sticky directories, unless the regular file is
> owned by the owner of the directory.

That makes no sense. In the absence of O_EXCL, O_CREAT pertains to files
that don't exist. Files that don't exist do not have an owner.

If the file exists, and O_CREAT is specified, but not O_EXCL, then
O_CREAT means nothing.

(If the file doesn't exist, the caller will own it when it gets created,
so "that the caller doesn't own" will not apply.)

> 2 As for the value 1, but the restriction also applies to
> group-writable sticky directories.
>
> The intent of the above protections is similar to protected_fifos, but
> allows an application to avoid writes to an attacker-controlled regular
> file, where the application expected to create one.

IF the application expects to create a file, it should specify
O_EXCL | O_CREAT. That will then fail if the file exists already.

If a file is attacker-controlled, that is independent of the
circumstances of its creation.

We can think about a protection mechanism that, in certain directories,
prevents a process from obtaining an open file descriptor to an
attacker-controlled file, regardless of whether it is being created.

Such a mechanism won't be looking at whether O_CREAT is present
in the open request, since it is bad to open an attacker-controlled
file whether creating it or not.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2024-05-23, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> /proc/sys/fs/protected_regular (since Linux 4.19)
>>
>> 1 Don't allow O_CREAT open(2) on regular files that the caller doesn't
>> own in world-writable sticky directories, unless the regular file is
>> owned by the owner of the directory.
>
> That makes no sense. In the absence of O_EXCL, O_CREAT pertains to files
> that don't exist. Files that don't exist do not have an owner.
>
> If the file exists, and O_CREAT is specified, but not O_EXCL, then
> O_CREAT means nothing.

This is obviously supposed to refer to the one use-case of O_CREAT the
guy who authored this could think of: Broken application trying to create a
temporary file in an insecure way. The application is broken as it would
need to use O_EXCL to achieve the intended semantics. This means this is
a workaround supposed to cause broken applications to fail in harmless
ways which happens to break correct application trying to cooperate with
other correct applications wrt using a partiuclar file.

It's basically a coded opinion statement: I the undersigned really think
O_CREAT should fail when the file already exists!

[...]

>> 2 As for the value 1, but the restriction also applies to
>> group-writable sticky directories.
>>
>> The intent of the above protections is similar to protected_fifos, but
>> allows an application to avoid writes to an attacker-controlled regular
>> file, where the application expected to create one.

[...]

> If a file is attacker-controlled, that is independent of the
> circumstances of its creation.
>
> We can think about a protection mechanism that, in certain directories,
> prevents a process from obtaining an open file descriptor to an
> attacker-controlled file, regardless of whether it is being created.

This leads to another question: What on G*ds f***ing earth is "an
attacker controlled regular file" security-wise? It's not that regular
files do anything. They just store data. I can think of seriously
contrived issue here, namely, broken app tries to create a file with
restrictive permissions in order to write $super_secret_stuff to it and
accidentally writes it to a file readable by another user instead. If
that's a real issue, I haven't heard of it yet. And I certainly don't
think this justifies breaking working, correct code which makes use of
UNIX semantics some Google employee happens to dislike.

"We must do something about security! This is said to be something about
security. Therefore, we must do it!" ("Yes minister" paraphrase).

On Fri, 24 May 2024 16:32:53 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>Kaz Kylheku <643-408-1753@kylheku.com> writes:
>> We can think about a protection mechanism that, in certain directories,
>> prevents a process from obtaining an open file descriptor to an
>> attacker-controlled file, regardless of whether it is being created.
>
>This leads to another question: What on G*ds f***ing earth is "an
>attacker controlled regular file" security-wise? It's not that regular
>files do anything. They just store data. I can think of seriously
>contrived issue here, namely, broken app tries to create a file with
>restrictive permissions in order to write $super_secret_stuff to it and
>accidentally writes it to a file readable by another user instead. If
>that's a real issue, I haven't heard of it yet. And I certainly don't
>think this justifies breaking working, correct code which makes use of
>UNIX semantics some Google employee happens to dislike.

Changing things that work because someone doesn't like them seems to be par for
the course these days. See systemd, wayland, pulse audio.

Some people can't or won't learn from what others have done before and think
they have some kind of magic insight into developing something better. Rarely
does that turn out to be the case.

Rainer Weikusat <rweikusat@talktalk.net> writes:
> This leads to another question: What on G*ds f***ing earth is "an
> attacker controlled regular file" security-wise? It's not that regular
> files do anything. They just store data. I can think of seriously
> contrived issue here, namely, broken app tries to create a file with
> restrictive permissions in order to write $super_secret_stuff to it and
> accidentally writes it to a file readable by another user instead. If
> that's a real issue, I haven't heard of it yet.

The typical example is an install script which downloads the main
installer to a predictable filename in /tmp and then executes it.
Broken, indeed, but nevertheless a recurring issue.

The attacker pre-creates the download file with 0777 permission and then
injects their own code into it; it will subsequently be run as the
victim user. There’s a race to win here, i.e. getting a modification in
before execution completes, but it seems to be easy in practice.

People presumably set protected_regular=0 if the attack scenario never
arises in their environment, or if they prefer to take the risk.

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

Richard Kettlewell <invalid@invalid.invalid> writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>> This leads to another question: What on G*ds f***ing earth is "an
>> attacker controlled regular file" security-wise? It's not that regular
>> files do anything. They just store data. I can think of seriously
>> contrived issue here, namely, broken app tries to create a file with
>> restrictive permissions in order to write $super_secret_stuff to it and
>> accidentally writes it to a file readable by another user instead. If
>> that's a real issue, I haven't heard of it yet.
>
> The typical example is an install script which downloads the main
> installer to a predictable filename in /tmp and then executes it.
> Broken, indeed, but nevertheless a recurring issue.

That's not really broken, only stupid. The broken bit is not using
O_EXCL to create the file. And the broken bit of the chokearound is
changing well-documented semantics of open flags with real uses cases
based on the assumption that O_EXCL must have been 'forgotten'.

> The attacker pre-creates the download file with 0777 permission and then
> injects their own code into it; it will subsequently be run as the
> victim user.
>
> There’s a race to win here, i.e. getting a modification in
> before execution completes, but it seems to be easy in practice.

There's another 'race' to win here, namely, it must somehow be known
that a broken install script is about to be executed in order to
'attack' anyone. And "download random crap from the internet and run it"
is a recipe for disaster, anyway: The 'install script' is already
running as "the victim user" and offers a much more direct route to
victimising someone.

> People presumably set protected_regular=0 if the attack scenario never
> arises in their environment, or if they prefer to take the risk.

If people actually do that (going against system defaults is an uphill
battle), sooner or later, a second control file will appear with values

0 - pay attention to the setting in the original file
1 - pay attention to the setting in the original fikle every 3rd Thursday
2 - break O_CREAT, correct code be fucked!

will appear (default again 2, obviously).

Rainer Weikusat <rweikusat@talktalk.net> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>> This leads to another question: What on G*ds f***ing earth is "an
>>> attacker controlled regular file" security-wise? It's not that regular
>>> files do anything. They just store data. I can think of seriously
>>> contrived issue here, namely, broken app tries to create a file with
>>> restrictive permissions in order to write $super_secret_stuff to it and
>>> accidentally writes it to a file readable by another user instead. If
>>> that's a real issue, I haven't heard of it yet.
>>
>> The typical example is an install script which downloads the main
>> installer to a predictable filename in /tmp and then executes it.
>> Broken, indeed, but nevertheless a recurring issue.
>
> That's not really broken, only stupid. The broken bit is not using
> O_EXCL to create the file. And the broken bit of the chokearound is
> changing well-documented semantics of open flags with real uses cases
> based on the assumption that O_EXCL must have been 'forgotten'.

The adjective used to describe it isn’t the point. The point is that it
keeps happening.

>> The attacker pre-creates the download file with 0777 permission and
>> then injects their own code into it; it will subsequently be run as
>> the victim user.
>>
>> There’s a race to win here, i.e. getting a modification in before
>> execution completes, but it seems to be easy in practice.
>
> There's another 'race' to win here, namely, it must somehow be known
> that a broken install script is about to be executed in order to
> 'attack' anyone.

Easy enough to arrange in a shared environment. Find a bit of software
relevant to the attacker’s job (or the job of whoever’s unprivileged
login they’ve compromised) and ask the IT department to install it.

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

Richard Kettlewell <invalid@invalid.invalid> writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>> This leads to another question: What on G*ds f***ing earth is "an
>>>> attacker controlled regular file" security-wise? It's not that regular
>>>> files do anything. They just store data. I can think of seriously
>>>> contrived issue here, namely, broken app tries to create a file with
>>>> restrictive permissions in order to write $super_secret_stuff to it and
>>>> accidentally writes it to a file readable by another user instead. If
>>>> that's a real issue, I haven't heard of it yet.
>>>
>>> The typical example is an install script which downloads the main
>>> installer to a predictable filename in /tmp and then executes it.
>>> Broken, indeed, but nevertheless a recurring issue.
>>
>> That's not really broken, only stupid. The broken bit is not using
>> O_EXCL to create the file. And the broken bit of the chokearound is
>> changing well-documented semantics of open flags with real uses cases
>> based on the assumption that O_EXCL must have been 'forgotten'.
>
> The adjective used to describe it isn’t the point. The point is that it
> keeps happening.

It doesn't "keep happening" as this is not a natural phenomenon. At
best, that's something (certain) people keep doing. I also very much
dispute that this is an actual phenomenon at all and not just some
theoretical justification someone came up with for breaking stuff.

To recapitulate

1, It is conjectured that "install scripts" exist which create
executable temporary files in /tmp incorrectly and idiotically, that is,
by neither using one of the functions for doing so securely (mkstemp,
tmpfile) nor the kernel facility for this (O_TMPFILE open flag) nor the
proper set of open flags (O_CREAT | O_EXCL) and by using /tmp instead of
a readily available directory that's not world-writable, eg, the home
directory of the user in question.

2. It is further conjectured that a hostile third party exists which can
observe another user running a particular broken script which downloads code to
such a file in order to replace the content of the file between the
close call of the broken script (necessary to avoid ETXTBSY errors) and
the following execve, thereby possibly leading to execution of code
provided by the hostile third party.

and because this is conjectured, it's considered ok to break working
correct code trying to open files shared with other application in group
writable directories with the sticky bit set by 'silently' changing the
semantics of O_CREAT to imply O_EXCL but with a different error code
(EACCES instead of EEXIST).

And the onus for coping with the change is - of course - not on the
people who want it because they believe it'll help them but on people
relying on standardized UNIX semantics which have been in place since
some time in the 1970s, ie, it's not "enable this behaviour if you think
that's a problem you'll need to deal with" but "disable this behaviour
after it has caused you grief".

>>> The attacker pre-creates the download file with 0777 permission and
>>> then injects their own code into it; it will subsequently be run as
>>> the victim user.
>>>
>>> There’s a race to win here, i.e. getting a modification in before
>>> execution completes, but it seems to be easy in practice.
>>
>> There's another 'race' to win here, namely, it must somehow be known
>> that a broken install script is about to be executed in order to
>> 'attack' anyone.
>
> Easy enough to arrange in a shared environment. Find a bit of software
> relevant to the attacker’s job (or the job of whoever’s unprivileged
> login they’ve compromised) and ask the IT department to install it.

And a practical example of this is? And when was it last used for an
actual exploit?

On Mon, 27 May 2024 09:19:30 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

> Easy enough to arrange in a shared environment. Find a bit of software
> relevant to the attacker’s job (or the job of whoever’s unprivileged
> login they’ve compromised) and ask the IT department to install it.

That's a social-engineering problem, not a software-engineering one.
Trying to solve "people in positions of responsibility aren't being
responsible" by technical means has never worked and *will* never work.

On 2024-05-28, John Ames <commodorejohn@gmail.com> wrote:
> On Mon, 27 May 2024 09:19:30 +0100
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>
>> Easy enough to arrange in a shared environment. Find a bit of software
>> relevant to the attacker’s job (or the job of whoever’s unprivileged
>> login they’ve compromised) and ask the IT department to install it.
>
> That's a social-engineering problem, not a software-engineering one.
> Trying to solve "people in positions of responsibility aren't being
> responsible" by technical means has never worked and *will* never work.

And when something doesn't work, alll that is left is its risks
and downsides.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Tue, 28 May 2024 07:57:07 -0700
John Ames <commodorejohn@gmail.com> wrote:

> That's a social-engineering problem, not a software-engineering one.
> Trying to solve "people in positions of responsibility aren't being
> responsible" by technical means has never worked and *will* never
> work.

(On top of which, if the concern really boils down to "filename
collisions in /tmp are exploitable," it seems like it'd be *vastly*
less hazard-prone to come up with some mechanism for making /tmp an
alias for a user-specific mount point, compared to changing behavior of
fundamental system calls!

At the very least, if /tmp isn't mounted as noexec, you should probably
be asking yourself if there's any reason it *couldn't* be.)

John Ames <commodorejohn@gmail.com> writes:
> On Tue, 28 May 2024 07:57:07 -0700
> John Ames <commodorejohn@gmail.com> wrote:
>
>> That's a social-engineering problem, not a software-engineering one.
>> Trying to solve "people in positions of responsibility aren't being
>> responsible" by technical means has never worked and *will* never
>> work.
>
> (On top of which, if the concern really boils down to "filename
> collisions in /tmp are exploitable,"

It's more like "Programs which wrongly assume they have exclusive
control over the filesystem name space, ie, which - due to lazinness or
incompetence of their resepective authors - fail to use the abundantly
availabe mechanisms for ensuring they exclusivley control 'their' names,
can be exploited."

And the workaround for this is "Define a heuristic in order classify
requests for non-exclusive access to file system names as likely
erronoeous and force them to fail based on this".

In it's most extreme form, this heuristic is "Directory is writable by
someone other than the directory owner, has the sticky bit set and the
accessed name isn't owned by the user the accessing process is running
as".

In my case, the directory in question is the top-level of a substree
used to provide an (OpenSSL-based) certificate authority. Day-to-day
operation of this CA, ie, issueing of certificates, are supposed to be
performed by a dedicated, unprivileged user allowed to create files in
the CA hierarchy by virtue of belonging the dedicated group created for
this purpose. But this user is not supposed to be allowed to remove
files of other users from the hierarchy (the top-level directory is
marked as sticky). A certain file in this hierarchy belonging to the
the user in question is used as (fcntl-based) lockfile to serialize
executions of a particular script. And the program trying to acquire
this lock tries to open lock files for exclusive access with O_RDWR |
O_CREAT. The idea behind this (not used here) is that such lockfiles can
be created on-the-fly. Assuming the file doesn't initially exist,
concurrent attempts to acquire the lock will cause the one which happens
to get to this first to create the file and all subsequent ones then
just open the already created file.

Unfortunately, this falls foul of the heuristic described above despite
it's not vulnerable to the supposed exploit.

On Tue, 28 May 2024 21:44:48 +0100
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>John Ames <commodorejohn@gmail.com> writes:
>> On Tue, 28 May 2024 07:57:07 -0700
>> John Ames <commodorejohn@gmail.com> wrote:
>>
>>> That's a social-engineering problem, not a software-engineering one.
>>> Trying to solve "people in positions of responsibility aren't being
>>> responsible" by technical means has never worked and *will* never
>>> work.
>>
>> (On top of which, if the concern really boils down to "filename
>> collisions in /tmp are exploitable,"
>
>It's more like "Programs which wrongly assume they have exclusive
>control over the filesystem name space, ie, which - due to lazinness or
>incompetence of their resepective authors - fail to use the abundantly
>availabe mechanisms for ensuring they exclusivley control 'their' names,
>can be exploited."

The simple answer being that no process uses /tmp unless it needs to share
data with another via files.

John Ames <commodorejohn@gmail.com> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Easy enough to arrange in a shared environment. Find a bit of software
>> relevant to the attacker’s job (or the job of whoever’s unprivileged
>> login they’ve compromised) and ask the IT department to install it.
>
> That's a social-engineering problem, not a software-engineering one.
> Trying to solve "people in positions of responsibility aren't being
> responsible" by technical means has never worked and *will* never work.

It’s easy to think of counterexamples: collision assist in a car, for
instance, or automatic braking systems in trains.

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

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

> John Ames <commodorejohn@gmail.com> writes:
> > That's a social-engineering problem, not a software-engineering one.
> > Trying to solve "people in positions of responsibility aren't being
> > responsible" by technical means has never worked and *will* never
> > work.
>
> It’s easy to think of counterexamples: collision assist in a car, for
> instance, or automatic braking systems in trains.

Minimal-assistance-in-the-absence-of-direct-supervision is a *very*
different thing from intelligent-override-of-deliberate-action.

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?

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.

John Ames <commodorejohn@gmail.com> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> John Ames <commodorejohn@gmail.com> writes:
>>> That's a social-engineering problem, not a software-engineering one.
>>> Trying to solve "people in positions of responsibility aren't being
>>> responsible" by technical means has never worked and *will* never
>>> work.
>>
>> It’s easy to think of counterexamples: collision assist in a car, for
>> instance, or automatic braking systems in trains.
>
> 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.

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

On 2024-05-29, Richard Kettlewell <invalid@invalid.invalid> wrote:
> John Ames <commodorejohn@gmail.com> writes:
>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> Easy enough to arrange in a shared environment. Find a bit of software
>>> relevant to the attacker’s job (or the job of whoever’s unprivileged
>>> login they’ve compromised) and ask the IT department to install it.
>>
>> That's a social-engineering problem, not a software-engineering one.
>> Trying to solve "people in positions of responsibility aren't being
>> responsible" by technical means has never worked and *will* never work.
>
> It’s easy to think of counterexamples: collision assist in a car, for
> instance, or automatic braking systems in trains.

Reacting to an emergency event in a millisecond isn't a social
engineering problem of someone being irresponsible. It's something
only technology can do.

Accidents happen to the responsible. You're not irresponsible on account
of trusting that the opposite vehicle will not abruptly cross the median
line into your path in the last moment of the approach. Yet, such a
thing happens in the world.

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.

On 29 May 2024 15:39:08 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>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?

Create a dot directory in the users home dir and use that. Which is what
a lot of applications have done for years. Obviously if the user has a quota
but the app wants to create gigabyte sized files then another approach is
needed, but for small files that arn't around for long it works fine.

On Wed, 29 May 2024 18:12:20 +0100
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.

Muttley@dastardlyhq.com writes:
>On Wed, 29 May 2024 18:12:20 +0100
>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.
>

$ man 1 mktemp

On Wed, 29 May 2024 17:32:06 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Wed, 29 May 2024 18:12:20 +0100
>>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.
>>
>
>$ man 1 mktemp

No thanks, particularly if NFS is involved anywhere.

On 5/29/24 12:06, Scott Lurndal wrote:
> 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}

That doesn't answer the question, it just moves it. With this
suggestion, the original question is equivalent to asking "what should
TMPDIR be set to?"