Re: List of bugs that *must* be fixed before releasing Slink
> > 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
( bcwhite@pobox.com )
-------------------------------------------------------------------------------
Warning: Dates on calendar are closer than they appear.
Reply to: