On Thu, 10 Mar 2005 17:08:55 +0100, Arjan van de Ven
<[EMAIL PROTECTED]> wrote:
> On Thu, 2005-03-10 at 17:00 +0100, Lorenzo Hernández García-Hierro
> wrote: it tries to fill the
> > ipaddr member of the task_struct structure with the IP address
> > associated to the user running @current
On Thu, 10 Mar 2005 17:08:55 +0100, Arjan van de Ven
[EMAIL PROTECTED] wrote:
On Thu, 2005-03-10 at 17:00 +0100, Lorenzo Hernández García-Hierro
wrote: it tries to fill the
ipaddr member of the task_struct structure with the IP address
associated to the user running @current task/process,if
On Thu, 2005-03-10 at 17:08 +0100, Arjan van de Ven wrote:
> On Thu, 2005-03-10 at 17:00 +0100, Lorenzo HernÃndez GarcÃa-Hierro
> wrote: it tries to fill the
> > ipaddr member of the task_struct structure with the IP address
> > associated to the user running @current task/process,if available.
>
Replying to Arjan van de Ven:
> On Thu, 2005-03-10 at 17:00 +0100, Lorenzo HernÃndez GarcÃa-Hierro
> wrote: it tries to fill the
> > ipaddr member of the task_struct structure with the IP address
> > associated to the user running @current task/process,if available.
>
> but... a use doesn't hane
On Thu, 2005-03-10 at 17:00 +0100, Lorenzo HernÃndez GarcÃa-Hierro
wrote: it tries to fill the
> ipaddr member of the task_struct structure with the IP address
> associated to the user running @current task/process,if available.
but... a use doesn't hane an IP. a host does.
-
To unsubscribe
El jue, 10-03-2005 a las 16:38 +0100, Arjan van de Ven escribió:
> but tasks don't have an IP address. Hosts do. Hosts can have
> multiple IP addresses. Both ipv4 and ipv6. Users don't have IP
> addresses either (they do have user IDs so that link is clear).
> I think I'm missing something
On Thu, 2005-03-10 at 16:28 +0100, Lorenzo HernÃndez GarcÃa-Hierro
wrote:
> > 2) Can you explain briefly what this is useful for?
>
> For keeping track on the "originating ip address of the
> task/process" (the ipv4 address of the user that started the
> task/process).
but tasks don't have
El jue, 10-03-2005 a las 15:26 +0100, Arjan van de Ven escribió:
> a few questions
> 1) Why is this a config option; if it's useful it should just be always
> on really
Just to be removed if it applies for mainline.
> 2) Can you explain briefly what this is useful for?
For keeping track on the
In article <[EMAIL PROTECTED]> (at Thu, 10 Mar 2005 15:16:42 +0100), Lorenzo
Hernández García-Hierro <[EMAIL PROTECTED]> says:
> Ported feature from grSecurity that makes possible to add an ipaddr
> entry in each /proc/ (/proc//ipaddr), where the task originating
> IP address is stored, and
On Thu, 2005-03-10 at 15:16 +0100, Lorenzo HernÃndez GarcÃa-Hierro
wrote:
> Ported feature from grSecurity that makes possible to add an ipaddr
> entry in each /proc/ (/proc//ipaddr), where the task originating
> IP address is stored, and subsequently made available (readable) by the
> process
>
Ported feature from grSecurity that makes possible to add an ipaddr
entry in each /proc/ (/proc//ipaddr), where the task originating
IP address is stored, and subsequently made available (readable) by the process
itself and also the root user with CAP_DAC_OVERRIDE capability (that can be
managed
Ported feature from grSecurity that makes possible to add an ipaddr
entry in each /proc/pid (/proc/pid/ipaddr), where the task originating
IP address is stored, and subsequently made available (readable) by the process
itself and also the root user with CAP_DAC_OVERRIDE capability (that can be
On Thu, 2005-03-10 at 15:16 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
Ported feature from grSecurity that makes possible to add an ipaddr
entry in each /proc/pid (/proc/pid/ipaddr), where the task originating
IP address is stored, and subsequently made available (readable) by the
process
In article [EMAIL PROTECTED] (at Thu, 10 Mar 2005 15:16:42 +0100), Lorenzo
Hernández García-Hierro [EMAIL PROTECTED] says:
Ported feature from grSecurity that makes possible to add an ipaddr
entry in each /proc/pid (/proc/pid/ipaddr), where the task originating
IP address is stored, and
El jue, 10-03-2005 a las 15:26 +0100, Arjan van de Ven escribió:
a few questions
1) Why is this a config option; if it's useful it should just be always
on really
Just to be removed if it applies for mainline.
2) Can you explain briefly what this is useful for?
For keeping track on the
On Thu, 2005-03-10 at 16:28 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
2) Can you explain briefly what this is useful for?
For keeping track on the originating ip address of the
task/process (the ipv4 address of the user that started the
task/process).
but tasks don't have an IP
El jue, 10-03-2005 a las 16:38 +0100, Arjan van de Ven escribió:
but tasks don't have an IP address. Hosts do. Hosts can have
multiple IP addresses. Both ipv4 and ipv6. Users don't have IP
addresses either (they do have user IDs so that link is clear).
I think I'm missing something big
On Thu, 2005-03-10 at 17:00 +0100, Lorenzo Hernndez Garca-Hierro
wrote: it tries to fill the
ipaddr member of the task_struct structure with the IP address
associated to the user running @current task/process,if available.
but... a use doesn't hane an IP. a host does.
-
To unsubscribe from
Replying to Arjan van de Ven:
On Thu, 2005-03-10 at 17:00 +0100, Lorenzo Hernndez Garca-Hierro
wrote: it tries to fill the
ipaddr member of the task_struct structure with the IP address
associated to the user running @current task/process,if available.
but... a use doesn't hane an IP. a
On Thu, 2005-03-10 at 17:08 +0100, Arjan van de Ven wrote:
On Thu, 2005-03-10 at 17:00 +0100, Lorenzo Hernndez Garca-Hierro
wrote: it tries to fill the
ipaddr member of the task_struct structure with the IP address
associated to the user running @current task/process,if available.
but...
20 matches
Mail list logo
