RE: TRG vger.timpanogas.org hacked
On Tue, 5 Jun 2001, Randal, Phil wrote: > Bind 8.2.4 was released on May 17th, with the standard > comment "BIND 8.2.4 is the latest version of ISC BIND 8. > We strongly recommend that you upgrade to BIND 9.1 or, if > that is not immediately possible, to BIND 8.2.4 due to > certain security vulnerabilities in previous versions." > > However, there are no release notes on ISC's web site, > and their vulnerabilities page lists no known security > flaws in Bind 8.2.3. > > But the paranoid part of me does wonder :-) There really are no known vulnerabilities in BIND 8.2.3. There are a number of bug fixes which would make upgrading a good idea, though. The "previous versions" mentioned were those earlier than 8.2.3. Brian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fix for include/linux/fs.h in 2.4.0 kernels
On 3 Feb 2001, Brian May wrote:
> > "Keith" == Keith Owens <[EMAIL PROTECTED]> writes:
>
> >> {PB} This was necessary for libc5, but is not correct when
> >> using glibc. Including the kernel header files directly in user
> >> programs usually does not work (see question 3.5). glibc
> >> provides its own and header files to replace
> >> them, and you may have to remove any symlink that you have in
> >> place before you install glibc. However, /usr/include/asm and
> >> /usr/include/linux should remain as they were.
> >>
> >> Keith, are you saying that glibc is wrong?
>
> Keith> Not me, Linus says that glibc is wrong.
>
> Keith> "I've asked glibc maintainers to stop the symlink
> Keith> insanity for the last few years now, but it doesn't seem to
> Keith> happen.
>
> Keith> Basically, that symlink should not be a symlink. It's a
> Keith> symlink for historical reasons, none of them very good any
> Keith> more (and haven't been for a long time), and it's a
> Keith> disaster unless you want to be a C library developer.
> Keith> Which not very many people want to be.
>
> Keith> The fact is, that the header files should match the
> Keith> library you link against, not the kernel you run on."
>
>
> I read Keith's response as: the symlink is wrong.
> I read the glib FAQ as: the symlink is wrong.
> I read Linus' response as: the symlink is wrong.
>
> Who is contradicting who here?
>
> (perhaps that last sentence in the glibc FAQ is confusing, however the
> rest of it clearly says that glibc contains its own version of those
> files, and a symlink should *not* be used. I think the part "[...] you
> may have to remove any symlink [...]" is clear enough).
No, it clearly says that glibc contains its own versions of the net/* and
scsi/* files, and that /usr/include/asm and /usr/include/linux should
remain as they were. Since they were symlinks in libc5 (which is what
'originally' seems to be referring to), they should still be symlinks.
Brian (who really doesn't care either way)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: thread group comments
On Fri, 1 Sep 2000, Linus Torvalds wrote: > > 3rd Problem: one uid/gid process-wide > > > > All the ID (uid/guid/euid/egid/...) must be process wide. The problem > > is similar to the signal handler. I think one should again keep the > > information exclusively in the master thread and have all others refer > > to this information. > > No, it would be another "clone" option. > > But I don't think this is performance-critical, and I don't think it is > something people really care about. So I'd be unlikely to handle this for > 2.4.x. I care. Having written lots of Linux-specific code in BIND 9 to work around this problem in LinuxThreads, I'd really like to see it work correctly (correctly meaning according to posix, in this case). Basically, on every non-Linux platform, we can start threads, parse the config file in a thread, create new privileged sockets to listen on, and then call setuid(). On Linux, that doesn't work, because the call to setuid() only affects the running thread, which means we need to rework the above logic into a capability-based mess. This is not a performnace critical operation, but not implementing in the kernel makes user space jump through some pretty large hoops. The solution would probably involve lots of inter-thread messages, which if I remember correctly, these changes were supposed to remove. I'd imagine other people have similar concerns... Brian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
