> > You know, I don't see this as "grave". It means that a user can > > effectively "export to the world" any file readable by www-data. In > > general, this means only things that can be read by public. So, > > the user can't intentionally export anything that he/she couldn't already > > do by other means. > > But there is a big difference between the local public that you might > trust and the big evil world outside your system.. I see two solutions > two this: enforce SymLinksIfOwnerMatch or don't allow userdirs. > > > The problem comes with unintentional exports... Well, it's a bug. I > > don't see it as being a security hole. > > You only hide information but don't disable any security issues, so it > is indeed not a real security hole in the canonical sense of the term.
I suppose that depends on what you make available. If a user created a link to /etc within their public_html, you could export some pretty bad stuff, especially if not using shadow passwords. That's pretty unlikely, though. > > > It's important but I wouldn't call this one release-critical. > > > > I looked at that one time, but I wasn't sure. Is it possible that during > > an upgrade to "stable" we get dpkg and dpkglib to be out-of-step? > > I don't think so; when dpkg upgrades itself and replaces the library it > still has the old library opened via a mmap() which means it won't > suddenly start using another incompatible library. This becomes a real > issue only when the library is split into its own package and the two > are upgraded independantly. Hmmm... If things were installed by hand ("dpkg --install dpkglib...") or if install were to fail between the two packages, then you could have a problem where the install tool doesn't function, right? Brian ( [EMAIL PROTECTED] ) ------------------------------------------------------------------------------- Warning: Dates on calendar are closer than they appear.