On 12/3/2013 8:18 AM, François Patte wrote:
Le 03/12/2013 14:07, Linux-Fan a écrit :
On 12/03/2013 10:50 AM, François Patte wrote:
You misunderstood the sentence: the file where the php command is
written is in /var/www and has 644 permissions... (/var/www has, of
course, 755 permissions).
Re-
Le 03/12/2013 14:07, Linux-Fan a écrit :
> On 12/03/2013 10:50 AM, François Patte wrote:
>> You misunderstood the sentence: the file where the php command is
>> written is in /var/www and has 644 permissions... (/var/www has, of
>> course, 755 permissions).
>>
>> Re-reading my first message, I can'
I ended up using aptitude safe-upgrade and it gave me no trouble.
On Wed, Jan 20, 2010 at 13:35, Virgo Pärna wrote:
> You need to have package installed, that provides phpapi-20060613.
> php5-cgi or php5-cli should also work.
I have both -cgi and -cli.
> I guess, that it is pretty much
, 2006 11:47 AM
To: [EMAIL PROTECTED]
Subject: Re: apache --SOLVED
Cary Pembleton wrote:
> Nice Job Mark,
> I checked it out and it works fine and looks fine from a public IP.
> Now if I could figure out how to do this, I would be thrilled! :o)
> Disclaimer: I am an IT consultant f
On 08/06/2006 09:37 AM, Mark Grieveson wrote:
[...]
Does anyone have any tips for ensuring that an apache setup reaches
the world at large (beyond the local host)?
Mark
Hello Mark.
Install 'apache-doc' and read the documentation in
/usr/share/doc/apache-doc to learn how to configure apach
Ok, Problem is solved, was my mistake... #-)
Thanx anyways...
Arne
On Thu, Sep 13, 2001 at 09:18:47PM -0400, Jason Boxman wrote:
> On Thursday 13 September 2001 03:57 pm, Dave Sherohman wrote:
> > I've got two machines here, one running stable (apache-perl 1.3.9)
> > and the other on testing with an unstable apache (apache 1.3.20 with
> > libapache-mod-perl 1.25 -
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
26 matches
Mail list logo
