> I get the distinct impression, based on `perldoc perlsec` that perl
> is smart enough to detect and circumvent the relevant
> vulnerabilities:
> on many
>versions of Unix, set-id scripts are inherently insecure
>right from the
On Fri, May 24, 2002 at 09:52:58AM -0600, Bob Proulx wrote:
> Note that whenever you make a script suid or sgid you are trading in
> your padlock for a breadtie. There are many well known trivial
> ways to fool a suid script into giving you a shell of the id it
> is set to.
I get the distinct imp
> The obvious solution, then, was to change the ownership of the
> command-line script to group www-data and make it sgid.
Note that whenever you make a script suid or sgid you are trading in
your padlock for a breadtie. There are many well known trivial
ways to fool a suid script into giving you
On Wed, May 22, 2002 at 07:55:08AM -0500, Dave Sherohman wrote:
> The obvious solution doesn't work. With sgid set, everyone except
> root gets "Permission denied." when they try to execute the utility.
The script was physically located in /home, which is mounted nosuid.
Copied it to /usr/local/b
At 2002-05-22T12:55:08Z, Dave Sherohman <[EMAIL PROTECTED]> writes:
> So, what do I need to do to make this work without adding all users of the
> command-line utility to group www-data or making the config file
> world-readable?
It seems like this is becoming my default answer, but:
Check out
The situation:
I've put some code together that runs mostly as a web-based app, but
also has a command-line utility. Its configuration includes a
database password, so I put the config into a file under /etc with
permissions 0640 owned by developer.www-data.
The problem, of course, is that, alth
6 matches
Mail list logo
