Robert Varga wrote:
>
> > > One important point about cgiwrap - the current debian package puts the
> > > user cgis in ~user/public_html/cgi-bin instead of ~user/cgi-bin. I've
> > > filed a bug about it. It's bad security for cgis and their associated
> > > datafiles to be web-readable. Yes, I k
On Sat, Feb 26, 2000 at 05:22:52PM +0100, Robert Varga wrote
>
>
> > > One important point about cgiwrap - the current debian package puts the
> > > user cgis in ~user/public_html/cgi-bin instead of ~user/cgi-bin. I've
> > > filed a bug about it. It's bad security for cgis and their associated
>
> It is automatic with suexec. Only you have to enable suexec by setting
> suexec setuid.
hrm, i thought i tried that and it didn't work. regardless, if you know how
then that's the main thing :)
> Unfortunately with apache, data is always served as www-data.www-data or
> whatever it is set to
On Sat, 26 Feb 2000, Adam Shand wrote:
>
> > That involves creating a virtual host for every user.
> >
> > I was asking whether ~user/cgi-bin can be made to be not under
> > /home/user/public_html/cgi-bin but /home/user/cgi-bin.
>
> with ~username urls it's even easier. i'm not sure how you d
> That involves creating a virtual host for every user.
>
> I was asking whether ~user/cgi-bin can be made to be not under
> /home/user/public_html/cgi-bin but /home/user/cgi-bin.
with ~username urls it's even easier. i'm not sure how you do it with
suexec cause i've never tried but with cgiwrap
On Sat, 26 Feb 2000, Adam Shand wrote:
>
> > And how can you set up /home//cgi-bin to be web-executable if you
> > cannot describe it with a web url?
>
> that's what aliases and scriptaliases are for. you would put in their
> virtualhost config (or just change the pathing cgiwrap's source) so
> And how can you set up /home//cgi-bin to be web-executable if you
> cannot describe it with a web url?
that's what aliases and scriptaliases are for. you would put in their
virtualhost config (or just change the pathing cgiwrap's source) something
like this:
ScriptAlias /cgi-bin/ /home/user/c
> > One important point about cgiwrap - the current debian package puts the
> > user cgis in ~user/public_html/cgi-bin instead of ~user/cgi-bin. I've
> > filed a bug about it. It's bad security for cgis and their associated
> > datafiles to be web-readable. Yes, I know security through obscurit
> > this doesn't really solve the problem. it means that users cgi's can't
> > screw with the server's stuff but it doesn't stop them from messing with
> > each others stuff.
>
> I was unclear, I meant create a second account for each user who wants
> her cgis sandboxed.
ah, yes. that would be
On Mon, Feb 21, 2000 at 09:33:53PM +0100, Robert Varga wrote:
> >
> If there is an exploitable cgi, then there is web access to all of the
> owning user's files. If it is not run via the suEXEC mechanism, then the
> permissions are that of www-data, which are close to nothing.
^^
> If there is an exploitable cgi, then there is web access to all of the
> owning user's files. If it is not run via the suEXEC mechanism, then the
> permissions are that of www-data, which are close to nothing.
except that suexec effectively chroot's the the virtuals document root
... so all of
> > It is not only what they write, but what they set the permissions to, as
> > well. I know, this is also what they should learn. But with
> > exploitable setuid cgi-s, and one can never be sure that his code is
> > unexploitable, not only his cgi datafiles, but all files can be accessed
> > and
Robert Varga wrote:
> > This is a good thing, IMO. Once students realize that it's their files
> > and quota that are going to be eaten up by runaway cgis, in my
> > experience they start paying more attention to what they're writing.
> >
>
> It is not only what they write, but what they set the
On Mon, 21 Feb 2000, Joe Block wrote:
> Robert Varga wrote:
> > If there is an exploitable cgi, then there is web access to all of the
> > owning user's files. If it is not run via the suEXEC mechanism, then the
> > permissions are that of www-data, which are close to nothing.
>
> Without using
Robert Varga wrote:
> If there is an exploitable cgi, then there is web access to all of the
> owning user's files. If it is not run via the suEXEC mechanism, then the
> permissions are that of www-data, which are close to nothing.
Without using suexec or cgiwrap, how do you keep each user's cgis
On Mon, 21 Feb 2000, Adam Shand wrote:
>
> > It is the way it is supposed to be.
>
> is there a something in the docs i missed explaining that this is what needs
> to be done? it took me a very frustrating hour to figure this out. if not
> it should be submitted as a documentation bug, right
> It is the way it is supposed to be.
is there a something in the docs i missed explaining that this is what needs
to be done? it took me a very frustrating hour to figure this out. if not
it should be submitted as a documentation bug, right?
> With suEXEC enabled, cgi-s run setuid-ed, which i
On Sun, 20 Feb 2000, Adam Shand wrote:
>
> > Here is a list of searches from the apache main site about suxec AND
> > security:
>
> thanks but i just figured it out. all that needed to happed was to have the
> suid bit set on the suexec binary.
>
> # chmod 4711 /usr/lib/apache/suexec
>
> th
> Here is a list of searches from the apache main site about suxec AND
> security:
thanks but i just figured it out. all that needed to happed was to have the
suid bit set on the suexec binary.
# chmod 4711 /usr/lib/apache/suexec
the log file shows that it is now detecting the suexec binary, a
19 matches
Mail list logo
