On Mon, December 4, 2006 6:55 am, Jochem Maas wrote:
> but given that the ENV var is only available to the shell php in
> currently running in (and any subshells) so
> the script is only vulnerable to mistakes/attacks from 'inside' the
> script - basically I'm assuming that
> whatever is stored in
Jochem Maas wrote:
[EMAIL PROTECTED] wrote:
You'd assume those ENV variables are secure.. or secure "enough". I know
there's no such thing as perfect security, but I still wonder if there's a better way.
Although at this point, if there was a way to read other process/subprocess ENV
variable
[EMAIL PROTECTED] wrote:
> You'd assume those ENV variables are secure.. or secure "enough". I know
> there's no such thing as perfect security, but I still wonder if there's a
> better way.
>
> Although at this point, if there was a way to read other process/subprocess
> ENV variables, it'd m
T.Lensselink wrote:
> Doesn't it show up on the phpinfo(); page under "Environment" when
> using the putenv(); call?
I'd be surprised - firstly I'm not dealing with 'pages' because the code
in question constitutes a cmdline script that only runs with the CLI version
of php; secondly the putenv() c
Doesn't it show up on the phpinfo(); page under "Environment" when
using the putenv(); call?
On Mon, 04 Dec 2006 13:55:56 +0100, Jochem Maas <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> If you did use ENV to set the username and password, you could always
> unset it using the same meth
You'd assume those ENV variables are secure.. or secure "enough". I know
there's no such thing as perfect security, but I still wonder if there's a
better way.
Although at this point, if there was a way to read other process/subprocess ENV
variables, it'd most likely be something an attacker w
[EMAIL PROTECTED] wrote:
> If you did use ENV to set the username and password, you could always unset
> it using the same method after you ran the mysql command. So it'd only be
> exposed for a very brief period of time and slightly less accessible than
> just running a process list.
>
indee
If you did use ENV to set the username and password, you could always unset it
using the same method after you ran the mysql command. So it'd only be exposed
for a very brief period of time and slightly less accessible than just running
a process list.
It still falls under the category of "sec
On Thu, November 30, 2006 12:29 pm, Edwin Barrios wrote:
> This is not triue because a shell vars declered on a shell is only
> exposed
> to its subshells, that means that only exec's and system functions
> calls
> into the php itself resive those vars declared into the php !
>
> You can see this a
Richard Lynch wrote:
> On Thu, November 30, 2006 9:59 am, Edwin Barrios wrote:
>> I don't know if my solution is better or not. but in one of my
>> programs i
>> had to make a backup online then my solution was to use shell vars to
>> put
>> important information like db_password . When we use pute
Hi .!
First of all . Pardon if my last mail was not undestable !!
Then Richrad said that, the following is a cons of my solution :
" A simple debug statement to dump out all of ENV / $_GLOBALS will expose
the password. So you have to ask yourself if you and all your employees
and all the sc
On 11/30/06, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Thu, November 30, 2006 9:59 am, Edwin Barrios wrote:
> I don't know if my solution is better or not. but in one of my
> programs i
> had to make a backup online then my solution was to use shell vars to
> put
> important information like d
On Thu, November 30, 2006 9:59 am, Edwin Barrios wrote:
> I don't know if my solution is better or not. but in one of my
> programs i
> had to make a backup online then my solution was to use shell vars to
> put
> important information like db_password . When we use putenv function
> those
> var on
Edwin Barrios wrote:
> Hi !.
>
> I don't know if my solution is better or not.
neither do I! but I'm certainly going to give the alternative a go and see
what exsact it shows in the process list.
thanks for the tip!
> but in one of my programs i
> had to make a backup online then my solution w
Hi !.
I don't know if my solution is better or not. but in one of my programs i
had to make a backup online then my solution was to use shell vars to put
important information like db_password . When we use putenv function those
var only exists on the current shell and on its subshells. In your c
Richard Lynch wrote:
> Don't use exec. ;-v
yeah - which is annoying because outside of php/exec() using the `cat
/path/2/myqyl/passwd`
trick works (i.e. ps doesn't give the passwd away)
thanks to everyone for there input - I have plenty to read/think about,
I send something back to the list when
Don't use exec. ;-v
Or, perhaps, write a shell script that reads the password and provides
it to MySQL somehow without invoking another exec of some kind.
You also could look into other MySQL authentication mechanisms such as
SSL keys and whatnot -- which I only vaguely recall seeing somewhere
in
[EMAIL PROTECTED] wrote:
Ah.. makes sense. Good old DOS is stupid enough not to card most times. You can create
a text file with a "Y" in it, and redirect it into a command like:
del . < y.txt
Guess that's not a pipe technically. And some commands may be smart enough to
prevent something
Ah.. makes sense. Good old DOS is stupid enough not to card most times. You
can create a text file with a "Y" in it, and redirect it into a command like:
del . < y.txt
Guess that's not a pipe technically. And some commands may be smart enough to
prevent something like this.
Thanks for the
[EMAIL PROTECTED] wrote:
I don't know if this would work, but maybe something like this:
cat /my/sql/root/passwd/file | mysql -h localhost --user=admin -D somedb <
"/my/import/script.sql" 2>&1
No idea if that'd work, but it might put you in the right ballpark.
You can't do this. The pipe get
Would it be possible, Jochem, to just make a shell script that does the call to
mysql and have PHP exec() the shell script?
I don't know if you'd have the same problem or not. I've never done something
like this in *nix and paid attention to the process list.
Also, I'm guessing you're seeing y
bruce wrote:
> hi jochem...
>
> if no one provides you with a solution.. you might replicate what's already
> been done in one of the php/mysql/web admin apps. given that these apps
> already manage the mysql functions, so i'm willing to bet that some of them
> have resolved this issue...
they do
hi jochem...
if no one provides you with a solution.. you might replicate what's already
been done in one of the php/mysql/web admin apps. given that these apps
already manage the mysql functions, so i'm willing to bet that some of them
have resolved this issue...
-Original Message-
Fro
23 matches
Mail list logo
