bug#12947: [brl...@debian.org: Bug#598018: install: temporary insecure file permissions]
On November 21, 2012 at 3:12 AM Paul Eggert wrote:
> I pushed this [...]
This is more of a question, and I may be wrong,
but isn't here still a race afterwards?
execve("src/ginstall", ["src/ginstall", "-g", "video", "-m",
"664", "src/ginstall", "/tmp/g"], ...) = 0
...
stat("src/ginstall", {st_dev=makedev(8, 16), st_ino=134447,
st_mode=S_IFREG|0755, st_nlink=1,
st_uid=1000, st_gid=100, ...}) = 0
lstat("/tmp/g", 0x7fff6458b750) = -1 ENOENT (No such file or
directory)
open("src/ginstall", O_RDONLY) = 3
fstat(3, {st_dev=makedev(8, 16), st_ino=134447,
st_mode=S_IFREG|0755, st_nlink=1,
st_uid=1000, st_gid=100, ...}) = 0
open("/tmp/g", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
fstat(4, {st_dev=makedev(8, 2), st_ino=18846,
st_mode=S_IFREG|0600, st_nlink=1,
st_uid=1000, st_gid=100, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
read(3, ..., 65536) = 65536
write(4, ..., 65536) = 65536
...
fchmod(4, 0600) = 0
close(4)= 0
close(3)= 0
<== ... race? ... ==>
lchown("/tmp/g", 4294967295, 33)= 0
chmod("/tmp/g", 0664) = 0
I.e., after closing FDs 4 and 3, the file "/tmp/g" could
have been replaced. Why aren't we using fchown and
fchmod_or_lchmod before the close() call?
Have a nice day,
Berny
bug#12947: [brl...@debian.org: Bug#598018: install: temporary insecure file permissions]
On 11/21/2012 02:27 AM, Bernhard Voelker wrote: > Why aren't we using fchown and > fchmod_or_lchmod before the close() call? The code used to do that, if memory serves, but then the code was modified to deal with ACLs or SELinux or whatever and it turned into a big mess, which I've been afraid to deal with. I vaguely recall that it had something to do with the relevant ACL and/or SELinux calls requiring file names (which seemed like a huge mistake to me at the time).
bug#12954: Differences between 'su' version give different results
Differences between 'su' version give different results in the following
shell script:
# !/bin/sh
func() {
su user > /dev/null 2>&1 << EOF
echo >> /tmp/b
EOF
}
if func; then
echo "access"
else
echo "no access"
fi
over fedora 17 I run - coreutils 8.15-8: if the file is not accessible
by user the script prints no access, and the other way around.
over rhel 6.3 we run - coreutils 8.4: the result of func is always
"access" without any dependency of the file permissions.. My first guess
was that it returns 0 because the 'su' command was succeeded, but with
strace you see that the script runs differently.
Is it a bug?
Thanks.
--
Yaniv Bronhaim.
RedHat, Israel
09-7692289
054-7744187
bug#12954: Differences between 'su' version give different results
tag 12954 notabug thanks On 11/21/2012 09:07 AM, ybronhei wrote: > Differences between 'su' version give different results in the following > shell script: > over fedora 17 I run - coreutils 8.15-8: if the file is not accessible > by user the script prints no access, and the other way around. > over rhel 6.3 we run - coreutils 8.4: the result of func is always > "access" without any dependency of the file permissions.. My first guess > was that it returns 0 because the 'su' command was succeeded, but with > strace you see that the script runs differently. > > Is it a bug? Thanks for the report. Perhaps it is a bug in the older coreutils 8.4 that was fixed for coreutils 8.15, although a quick read through NEWS didn't find such a mention (only that 8.9 was the point at which upstream quit building su by default, and therefore Fedora 17 is using a non-default build in order to get su from coreutils 8.15). Or it could be a patch that is applied to Fedora but not to RHEL. Either way, upstream coreutils no longer maintains coreutils (newer distros, such as Fedora 18, use 'su' from util-linux); furthermore, upstream, we only focus on fixing current bugs, and not on backporting fixes to older releases. So your question should be redirected downstream to your particular distro (that is, please file a support request with Red Hat), as it is not something we are worried about here. I'm closing this bug report because there is nothing further to do upstream; but obviously the issue is real for your setup, and you should feel free to send further replies if you have more questions and/or file a downstream bug and want to post the results of that downstream bug resolution back to this list. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
