https://issues.dlang.org/show_bug.cgi?id=16568

TIA! -- Andrei

On Saturday, 1 October 2016 at 16:05:25 UTC, Andrei Alexandrescu wrote:
> https://issues.dlang.org/show_bug.cgi?id=16568
>
> TIA! -- Andrei

Please post some code/instructions to reproduce the issue.

The fix for this will be quite simple create a directory with the DDMMYY timestamp as directory name, and bundle the files under it.

On Saturday, 1 October 2016 at 16:43:29 UTC, Stefan Koch wrote:
> On Saturday, 1 October 2016 at 16:05:25 UTC, Andrei Alexandrescu wrote:
>> https://issues.dlang.org/show_bug.cgi?id=16568
>>
>> TIA! -- Andrei
>
> Please post some code/instructions to reproduce the issue.
>
> The fix for this will be quite simple create a directory with the DDMMYY timestamp as directory name, and bundle the files under it.

Any predictable name is a security issue.  Use e.g. mkdtemp.

On Saturday, 1 October 2016 at 16:46:56 UTC, Guillaume Boucher wrote:
> On Saturday, 1 October 2016 at 16:43:29 UTC, Stefan Koch wrote:
>> On Saturday, 1 October 2016 at 16:05:25 UTC, Andrei Alexandrescu wrote:
>>> https://issues.dlang.org/show_bug.cgi?id=16568
>>>
>>> TIA! -- Andrei
>>
>> Please post some code/instructions to reproduce the issue.
>>
>> The fix for this will be quite simple create a directory with the DDMMYY timestamp as directory name, and bundle the files under it.
>
> Any predictable name is a security issue.  Use e.g. mkdtemp.

Well I guess checking for 700 is sufficient.  But this does not scale with multiple users.

On 10/01/2016 12:58 PM, Guillaume Boucher wrote:
> On Saturday, 1 October 2016 at 16:46:56 UTC, Guillaume Boucher wrote:
>> On Saturday, 1 October 2016 at 16:43:29 UTC, Stefan Koch wrote:
>>> On Saturday, 1 October 2016 at 16:05:25 UTC, Andrei Alexandrescu wrote:
>>>> https://issues.dlang.org/show_bug.cgi?id=16568
>>>>
>>>> TIA! -- Andrei
>>>
>>> Please post some code/instructions to reproduce the issue.
>>>
>>> The fix for this will be quite simple create a directory with the
>>> DDMMYY timestamp as directory name, and bundle the files under it.
>>
>> Any predictable name is a security issue.  Use e.g. mkdtemp.
>
> Well I guess checking for 700 is sufficient.  But this does not scale
> with multiple users.

I think /tmp/ is mounted per user so we should be good. Anyhow... care to send a PR upstream? -- Andrei

On Saturday, 1 October 2016 at 17:35:29 UTC, Andrei Alexandrescu wrote:
> I think /tmp/ is mounted per user so we should be good. Anyhow... care to send a PR upstream? -- Andrei

You can't make any assumptions about how /tmp/ is mounted, it is completely up to distro/administrator.

On Saturday, 1 October 2016 at 17:45:30 UTC, Dicebot wrote:
> On Saturday, 1 October 2016 at 17:35:29 UTC, Andrei Alexandrescu wrote:
>> I think /tmp/ is mounted per user so we should be good. Anyhow... care to send a PR upstream? -- Andrei
>
> You can't make any assumptions about how /tmp/ is mounted, it is completely up to distro/administrator.

As for original post - it is not an issue. The whole /tmp/ content can be wiped between sessions (it is not uncommon to mount it into RAM) - there should never be need to only remove dmd related parts. The whole point of /tmp/ is to be a random junkyard.

On 10/01/2016 01:48 PM, Dicebot wrote:
> On Saturday, 1 October 2016 at 17:45:30 UTC, Dicebot wrote:
>> On Saturday, 1 October 2016 at 17:35:29 UTC, Andrei Alexandrescu wrote:
>>> I think /tmp/ is mounted per user so we should be good. Anyhow...
>>> care to send a PR upstream? -- Andrei
>>
>> You can't make any assumptions about how /tmp/ is mounted, it is
>> completely up to distro/administrator.
>
> As for original post - it is not an issue. The whole /tmp/ content can
> be wiped between sessions (it is not uncommon to mount it into RAM) -
> there should never be need to only remove dmd related parts. The whole
> point of /tmp/ is to be a random junkyard.

Granted, no contest. Seems to me we could be a better denizen of said junkyard. What I noticed other apps do is create one directory in /tmp and then place their junk in there. -- Andrei

On Saturday, 1 October 2016 at 18:24:07 UTC, Andrei Alexandrescu wrote:
> Granted, no contest. Seems to me we could be a better denizen of said junkyard. What I noticed other apps do is create one directory in /tmp and then place their junk in there. -- Andrei

Yeah, it is both common and "wrong" (considered insecure) :) Problem is that it allows one to hijack output from the binary and redirect it somewhere else. If binary is running as privileged user, it can possibly be used as an attack vector.

Not like this is real security concern in dmd case but guidelines like "don't make /tmp/ path predictable" exist exactly so that one can have simple safe default and not worry about possibilities.

Sure, it makes things less pretty, but beauty of /tmp/ layout is hardly an important goal to follow. It seems like more practical issue is simply that no regular destruction of /tmp/ happens on your system.

On 10/01/2016 03:29 PM, Dicebot wrote:
> On Saturday, 1 October 2016 at 18:24:07 UTC, Andrei Alexandrescu wrote:
>> Granted, no contest. Seems to me we could be a better denizen of said
>> junkyard. What I noticed other apps do is create one directory in /tmp
>> and then place their junk in there. -- Andrei
>
> Yeah, it is both common and "wrong" (considered insecure) :) Problem is
> that it allows one to hijack output from the binary and redirect it
> somewhere else. If binary is running as privileged user, it can possibly
> be used as an attack vector.

Understood, thanks.

> Not like this is real security concern in dmd case but guidelines like
> "don't make /tmp/ path predictable" exist exactly so that one can have
> simple safe default and not worry about possibilities.

This may be a misunderstanding. I'm saying is to switch from unpredictable paths rooted in /tmp/ to equally unpredictable paths rooted in /tmp/.dmd-test-run/.


Thanks,

Andrei