Re: Hi honey. It is of course Cutey Julie

hi honey how are you doing.

Re: iptable: --seconds

Sorry for the late reply, I only saw this msg. now... Gerhard Kroder ([EMAIL PROTECTED]) wrote on 4 December 2005 23:07: >i want to stop sshd account testing by scripties witht the >followoing iptables/bash script, but it won't do what i thougt. On >a sarge test host with 2 aliased nic (eth0:1

Re: Security implications of allowing init to re-exec from another path

On Thu, Jan 05, 2006 at 09:54:59AM -0200, Henrique de Moraes Holschuh wrote: Just to make the question a bit more clear for those not reading the bug report, the real question is, are we causing problems for people who run / read-only (imagine read-only media) and their security expectations? S

unsubscribe

unsubscribe

Re: question on having . as LOAD_PATH (ruby)

* Junichi Uekawa: > Hi perl and pyhton people, > > Sorry for the crosspost; contrary to what's said in perl-policy and > python-policy, '.' seems to be included in module search-path. I find > it uneasy considering we have quite a few tools running as root. Is > this intentional or unintentional?

Re: question on having . as LOAD_PATH (ruby)

Hi perl and pyhton people, Sorry for the crosspost; contrary to what's said in perl-policy and python-policy, '.' seems to be included in module search-path. I find it uneasy considering we have quite a few tools running as root. Is this intentional or unintentional? regards, junichi

Re: question on having . as LOAD_PATH (ruby)

Hi, > > Hi, > > > > I am wondering what the security implications of having a LOAD_PATH > > that includes '.' is. > > Gerenally speaking, having . in any path is a bad idea. You are correct > to feel uneasy about it. Can . not be prepended to the path > specifically if desired (as in the shell