[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: sed umsak confusion
From: |
Assaf Gordon |
Subject: |
Fwd: sed umsak confusion |
Date: |
Sat, 31 Aug 2019 11:24:29 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
Forwarding an off-list message to sed-devel@.
Will push the attached patch in few days unless there are further comments.
-assaf
-------- Forwarded Message --------
Subject: sed umsak confusion
Date: Fri, 30 Aug 2019 21:09:49 +0100
From: Dr N.W. Filardo <address@hidden>
Hello!
This commit
http://git.savannah.gnu.org/cgit/sed.git/commit/sed/utils.c?id=5156c19b23c41f438bf8658e1b9a43a5ff136835
introduces umask() operations around the use of mkostemp(). However, it
gets the
meaning of the mask backwards: it sets it to 0700, thereby stripping
permissions
of the creating user but allowing any set*, group, or other bits to be set.
I believe the intended value was 07077.
The net effect is that this patch does not do what it says on the tin:
it does not
improve the security story at all. Things continue to function because
the subsequent
operations are via f*() APIs, which take the open file handle, and in
particular
fchmod() will put the bits back to something sensible.
However, when running atop, for example, fuse-style filesystems which do
not keep open
descriptors to underlying files, this is catastrophic: the underlying
file will have
I_SRWXU of zero, and so the filesystem server will be unable to open the
file for the
fchmod() and that's the end of that.
If this could be corrected in the next release, that would be fantastic.
Thank you.
--nwf;
0001-sed-set-correct-umask-on-temporary-files.patch
Description: Text Data
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Fwd: sed umsak confusion,
Assaf Gordon <=