The existing PR does not look bad to me, don't have an ubuntu at hand right now. I guess if it works with Ubuntu 18.04, then we can merge it - as anything older is ancient anyway.
@matze, I think there is one important point to highlight: the attack for predictable names only applies to directories that are user writable. Typically mktemp and friends have to deal with…
LGTM - please go ahead. I'd suggest we make a major release out of this one, as changes on the file type affect basically everyone. So if we screwed something up, we have at least an indicator for…
mktemp works differently. What we are doing now is similar to mktemp -u.
Again, whether this is an actual problem, is a different question.
The typical issue mktemp is trying to solve:
*…
Guys,
I think we are having a security problem here.
Let's say we __file /some/dir/foo and a user has write access to /some/dir and the user can run ps on the target system.
Thus the…
Just wondering, are we adding a behaviour change here? I.e. before we unconditionally deleted the file/directory/socket/whatever. Now we fail if it exists?
You are right, we did not really consider the IPC between code-local and code-remote on the remote side.
I tested using a copy of the __file type:
destination="/$__object_id"
source="…
If I am not mistaken and the cdist-reference so far agrees with be, the $__object variable is available for code:
__object
Directory that contains the current object.
…
Hey Mark,
I was thinking in a similar direction, that the mv should just be on "on the other side".
One problem that we have as a base is, where to temporarily copy the file over and do we…
Thanks a lot for the insight, @mark! And I get the problem and rephrasing it in my own words for a later reference:
- One object is modifying the behaviour of sshd in code-local
- cdist fails…
Hey @mark! Thanks for the PR.
I am not fully getting the impact just yet, but moving the whole logic into __gencode_local as a starter "feels" wrong (doesn't mean your solution is right).
…
