Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
Hi, Nicolas Boulenguez wrote: --- bash-4.2/debian/changelog +++ bash-4.2/debian/changelog @@ -1,3 +1,10 @@ +bash (4.2-5.1) unstable; urgency=low + + * Non-maintainer upload. + * debian/bash.preinst-lib.c: typo in fcntl argument (Closes: #679198). It would be clearer to users (who generally see the changelog without the patch) to say something like * bash.preinst: pass F_GETFD/F_SETFD, not F_GETFL/F_SETFL, to fcntl to set FD_CLOEXEC flag, avoiding Inappropriate ioctl for device errors installing using the upstream FreeBSD kernel (Closes: #679198) But that's a small detail. What you've already written is fine. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
Package: bash
Followup-For: Bug #679198
If I understand well fcntl(2), the following patch may solve this bug.
Stefan, would you please try to rebuild and test?
--- bash.preinst-lib.c 2012-11-28 15:56:04.0 +0100
+++ bash.preinst-lib.c.new 2012-11-28 17:07:09.0 +0100
@@ -60,8 +60,8 @@
void set_cloexec(int fd)
{
- int flags = fcntl(fd, F_GETFL);
- if (flags 0 || fcntl(fd, F_SETFL, flags | FD_CLOEXEC))
+ int flags = fcntl(fd, F_GETFD);
+ if (flags 0 || fcntl(fd, F_SETFD, flags | FD_CLOEXEC))
die_errno(cannot set close-on-exec flag);
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
Control: tags -1 patch On 03/07/12 17:47, Jonathan Nieder wrote: F_GETFL is 3, so fcntl is being called correctly. But why does fcntl(F_GETFL) return 1 (== FD_CLOEXEC)? This looks like a bug. On 28/11/12 16:17, Nicolas Boulenguez wrote: - int flags = fcntl(fd, F_GETFL); - if (flags 0 || fcntl(fd, F_SETFL, flags | FD_CLOEXEC)) + int flags = fcntl(fd, F_GETFD); + if (flags 0 || fcntl(fd, F_SETFD, flags | FD_CLOEXEC)) Of course! How did we miss that? The fcntl calls are getting/setting the wrong flags here and returning 1 (== O_WRONLY) rather than 1 (== FD_CLOEXEC). This explains why it wasn't reproducible on Debian's own kfreebsd (kernel) builds. O_CLOEXEC is undefined in GNU/kFreeBSD's glibc and it doesn't appear in the F_GETFL result. But when running in a jail on upstream FreeBSD kernels, it must be getting 0x0011 (== O_WRONLY | O_CLOEXEC), and then it tries to F_SETFL with a flag our glibc won't recognise. Thanks a lot for this Nicolas! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
Nicolas Boulenguez wrote:
If I understand well fcntl(2), the following patch may solve this bug.
Stefan, would you please try to rebuild and test?
--- bash.preinst-lib.c 2012-11-28 15:56:04.0 +0100
+++ bash.preinst-lib.c.new 2012-11-28 17:07:09.0 +0100
@@ -60,8 +60,8 @@
void set_cloexec(int fd)
{
- int flags = fcntl(fd, F_GETFL);
- if (flags 0 || fcntl(fd, F_SETFL, flags | FD_CLOEXEC))
+ int flags = fcntl(fd, F_GETFD);
+ if (flags 0 || fcntl(fd, F_SETFD, flags | FD_CLOEXEC))
die_errno(cannot set close-on-exec flag);
Good eyes. Thanks for figuring it out.
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
On 30/06/12 04:23, Jonathan Nieder wrote: When did O_CLOEXEC get involved? This report was about a use of FD_CLOEXEC. I've been *assuming* (as the only thing that makes sense) the situation is something like: Enabling FD_CLOEXEC on an open fd was previously not implemented (in the upstream kernel that we shipped with squeeze). So I think O_CLOEXEC is considered as zero such that: sink = open(/dev/null, O_WRONLY) is taken by our kernels to imply O_CLOEXEC unconditionally. Any fcntl() trying to enable it later would be a no-op. But Stefan was trying to run a GNU/kFreeBSD userland on an upstream FreeBSD kernel with FD_CLOEXEC support. This won't assume an implicit O_CLOEXEC, yet our glibc still doesn't know how to enable FD_CLOEXEC and returns an error. So I suppose there might be a way to implement FD_CLOEXEC (to cater for this special case) without implementing the O_CLOEXEC option yet. If any of the above was a correct assumption. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
reassign 679198 src:kfreebsd-9 affects 679198 src:bash retitle 679198 bash: [on native FreeBSD] unable to set FD_CLOEXEC flag thanks On 29/06/12 03:19, Stefan Ott wrote: I suppose that narrows it down a little. I'm more and more inclined to blame ZFS. But /dev/null itself is on a devfs so I doubt it could have any effect. 74149 preinst CALL open(0x401ae4,0x1invalid1,unused0) 74149 preinst NAMI /dev/null 74149 preinst RET open 3 74149 preinst CALL fcntl(0x3,invalid=3,0) 74149 preinst RET fcntl 1 74149 preinst CALL fcntl(0x3,invalid=4,0x1invalid1) 74149 preinst RET fcntl -1 errno 25 Inappropriate ioctl for device There is a crucial difference; in my ktrace (with GNU/kFreeBSD host) the file was opened with the FD_CLOEXEC flag set already. Not sure how that happens, but I guess something different in how our kernel is built. In the above (with upstream FreeBSD as host) it was not, and trying to enable it failed. From reading http://bugs.debian.org/635192 it sounds like that might be a limitation of our glibc. Implementing it could be a problem for the 8.1 kernel of squeeze and as used on our buildds, and so I don't think it could be properly fixed until wheezy+1, at least. A workaround in bash might have been justified, but AFAIK this problem is specific to GNU/kFreeBSD chroot/jails on native FreeBSD hosts. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
On Fri, Jun 29, 2012 at 1:41 PM, Steven Chamberlain ste...@pyro.eu.org wrote: reassign 679198 src:kfreebsd-9 affects 679198 src:bash retitle 679198 bash: [on native FreeBSD] unable to set FD_CLOEXEC flag thanks On 29/06/12 03:19, Stefan Ott wrote: I suppose that narrows it down a little. I'm more and more inclined to blame ZFS. But /dev/null itself is on a devfs so I doubt it could have any effect. Ha, good point, I guess it's too hot for me to think properly atm. 74149 preinst CALL open(0x401ae4,0x1invalid1,unused0) 74149 preinst NAMI /dev/null 74149 preinst RET open 3 74149 preinst CALL fcntl(0x3,invalid=3,0) 74149 preinst RET fcntl 1 74149 preinst CALL fcntl(0x3,invalid=4,0x1invalid1) 74149 preinst RET fcntl -1 errno 25 Inappropriate ioctl for device There is a crucial difference; in my ktrace (with GNU/kFreeBSD host) the file was opened with the FD_CLOEXEC flag set already. Not sure how that happens, but I guess something different in how our kernel is built. Interesting. If you have a ideas / patches that I could try out I would be happy to. In the above (with upstream FreeBSD as host) it was not, and trying to enable it failed. From reading http://bugs.debian.org/635192 it sounds like that might be a limitation of our glibc. Ah indeed, that does look related. Implementing it could be a problem for the 8.1 kernel of squeeze and as used on our buildds, and so I don't think it could be properly fixed until wheezy+1, at least. A workaround in bash might have been justified, but AFAIK this problem is specific to GNU/kFreeBSD chroot/jails on native FreeBSD hosts. True, it's probably a rare combination. I suppose if it affects just me you can leave it for now, the next couple of months will tell us whether anyone else is running this combination. cheers thanks for looking into it -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
On 29/06/12 14:12, Stefan Ott wrote: Interesting. If you have a ideas / patches that I could try out I would be happy to. You could rebuild bash with Jonathan Nieder's patch, and use it locally http://lists.debian.org/20120627015952.GH7701@burratino It would be nice to fix this, as bash is an essential package which I guess would cause a problem during debootstrap. But fixing this isn't release-critical, would require a freeze exemption, and it is extra important that a fix wouldn't affect bash on other architectures. In the longer term it would be better that our kernels and glibc can implement the correct fix, and leave bash unmodified, as there are probably other packages we don't know about with related problems. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: Processed: Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
reassign 679198 bash thanks 2012/6/29 Debian Bug Tracking System ow...@bugs.debian.org: Processing commands for cont...@bugs.debian.org: reassign 679198 src:kfreebsd-9 This isn't a kernel bug. The kernel recognizes O_CLOEXEC properly when userland uses it. The problem is that userland isn't actually using O_CLOEXEC, because its declaration is missing in glibc headers. Actually it's already been reported: see #679198. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: Processed: Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
On 29/06/12 20:28, Robert Millan wrote: The problem is that userland isn't actually using O_CLOEXEC, because its declaration is missing in glibc headers. Actually it's already been reported: see #679198. #679198 is this bug. Did you mean #635192? In /usr/include/i386-kfreebsd-gnu/bits/fcntl.h : #if _POSIX_C_SOURCE = 200809L #define O_TTY_INIT 0x0008 /* Restore default termios attributes */ /* Defining O_CLOEXEC would break kfreebsd 8.1, see #635192 */ /* #define O_CLOEXEC0x0010 */ #endif So it is undefined on purpose? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635192: Processed: Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
2012/6/29 Steven Chamberlain ste...@pyro.eu.org: #679198 is this bug. Did you mean #635192? Yes, sorry. In /usr/include/i386-kfreebsd-gnu/bits/fcntl.h : #if _POSIX_C_SOURCE = 200809L #define O_TTY_INIT 0x0008 /* Restore default termios attributes */ /* Defining O_CLOEXEC would break kfreebsd 8.1, see #635192 */ /* #define O_CLOEXEC 0x0010 */ #endif So it is undefined on purpose? Correct. Although leaving it undefined might be worse than defining it. E.g. consider programs doing: /* use O_CLOEXEC if possible */ #ifndef O_CLOEXEC #define O_CLOEXEC 0 #endif fd = open (..., O_CLOEXEC); // don't bother closing fd But the decision is up to glibc maintainers. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679198: bash: [on native FreeBSD] unable to set FD_CLOEXEC flag
Hi Robert, Robert Millan wrote: This isn't a kernel bug. The kernel recognizes O_CLOEXEC properly when userland uses it. The problem is that userland isn't actually using O_CLOEXEC, because its declaration is missing in glibc headers. Actually it's already been reported: see #679198. When did O_CLOEXEC get involved? This report was about a use of FD_CLOEXEC. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
