[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?

                                  ( bcwhite@pobox.com )

            Warning: Dates on calendar are closer than they appear.

Reply to: