= this is like playing with UIDs, which are in the context of the
application and can be set by set[e]uid() co, to permit or deny access to
privileged ports. My idea is to tune the context before performing some
operations and to reset it after to its previous setup.
While the semantics of
(In this reply, I'm very specific to the BSD kernel, which may not be
appropriate in this list. If the discussion continues on this
particular topic, I'll change the place.)
On Sun, 23 Mar 2003 22:46:51 +0100,
Francis Dupont [EMAIL PROTECTED] said:
= I have a major concern about the
= what I propose is not pure per-process control, it is to put the
control in the context of processes. It gives immediatly a per-process
control but with a way to manage the context from applications, it gives
a per-socket control too.
Francis,
I didn't understand how the per-process
In your previous mail you wrote:
= what I propose is not pure per-process control, it is to put the
control in the context of processes. It gives immediatly a per-process
control but with a way to manage the context from applications, it gives
a per-socket control too.
I
]
Sent: Friday, March 21, 2003 11:52 AM
To: Francis Dupont
Cc: Samita Chakrabarti; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [mobile-ip] Draft on IPv6 source address
selection socket API
Some details:
..., CGA (cryptographically
On CGA. It is different now. We face mass deployment of required security
worldwide and I hear it all the time now. CGA being a base for our
addresses is far different scope of use than RSA mumbo-jumbo et al. The IPR
is a real problem and I think a show stopper. There can be no vendor
]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [mobile-ip] Draft on IPv6 source address
selection socket API
On CGA. It is different now. We face mass deployment of required
security worldwide and I hear it all the time now. CGA
being a base
for our addresses is far
Francis Dupont wrote:
In your previous mail you wrote:
and it can also satisfy per process behavior.
= this is not true: I don't want to patch and recompile all
applications. My concern is you provide a device then look for its
usage, I prefer to get requirements and
In your previous mail you wrote:
The goal of that API is to provide a simple way to manage socket level
preference.
= my concern is your goal is to fulfill a requirement from developpers
than my goal is to fulfill a similar requirement from users. As there
are far more users than
On Fri, 21 Mar 2003 00:39:12 +0100,
Francis Dupont [EMAIL PROTECTED] said:
A draft has been submitted to address source address selection at
the per-socket (and per apps) basis. Currently it discusses preferences
of source address selection by the application for privacy addresses,
In your previous mail you wrote:
On Fri, 21 Mar 2003 00:39:12 +0100,
Francis Dupont [EMAIL PROTECTED] said:
A draft has been submitted to address source address selection at
the per-socket (and per apps) basis. Currently it discusses preferences
of source
and it can also satisfy per process behavior.
= this is not true: I don't want to patch and recompile all applications.
My concern is you provide a device then look for its usage, I prefer to
get requirements and only after look for ways to satify them.
I assume these socket
In your previous mail you wrote:
As Erik explained before, having per-socket knob provides better control
on the implementation pieces
= no, it gives the same kind of control, and only in modified pieces
of code.
and it can also satisfy per process behavior.
= this is not true: I
The following flags are added for the ai_flags in addrinfo data
structure defined in Basic IPv6 Socket API Extension [2].
AI_PREFER_SRC_HOME
AI_PREFER_SRC_COA
AI_PREFER_SRC_TMP
AI_PREFER_SRC_PUBLIC
AI_PREFER_SRC_CGA
Some details:
..., CGA (cryptographically
generated addresses) and non-CGA addresses etc..
= you should note that CGAs are covered by some IPRs.
While I'm concerned about IPR and the IPR on CGA, I don't see
the benefit of cluttering every document and slide
In your previous mail you wrote:
What I propose is to put the policy in the context of applications
(Unix user structure, environment, etc, even monitors have this kind
of things) so one can tune the address selection before launching
applications. When the context can be managed
In your previous mail you wrote:
The following flags are added for the ai_flags in addrinfo data
structure defined in Basic IPv6 Socket API Extension [2].
AI_PREFER_SRC_HOME
AI_PREFER_SRC_COA
AI_PREFER_SRC_TMP
In your previous mail you wrote:
BTW, I am a bit concerned about applications that need to modify their own
context. How do you handle the case of an application which have several
threads of execution trying to modify a single context in a
contradictory way (e.g. TMP vs PUB, etc.)
context. How do you handle the case of an application which have several
threads of execution trying to modify a single context in a
contradictory way (e.g. TMP vs PUB, etc.) ?
= this is an implementation problem: there are a lot of possible
solutions: use a lock, use a
On Sat, 22 Mar 2003 [EMAIL PROTECTED] wrote:
The following flags are added for the ai_flags in addrinfo data
structure defined in Basic IPv6 Socket API Extension [2].
AI_PREFER_SRC_HOME
AI_PREFER_SRC_COA
AI_PREFER_SRC_TMP
I don't understand how can flags to getaddrinfo(3) affect source
address selection. where does it take effect in the following code?
getaddrinfo implementation itself? of course, then libc would have to
aware of src addresses and such..
getaddrinfo(3) does not open socket,
[EMAIL PROTECTED] said:
I don't understand how can flags to getaddrinfo(3) affect source
address selection. where does it take effect in the following code?
getaddrinfo implementation itself? of course, then libc would have to
aware of src addresses and such..
[EMAIL PROTECTED] said:
I don't understand how can flags to getaddrinfo(3) affect source
address selection. where does it take effect in the following code?
getaddrinfo implementation itself? of course, then libc would have to
aware of src addresses and such..
In your previous mail you wrote:
A draft has been submitted to address source address selection at
the per-socket (and per apps) basis. Currently it discusses preferences
of source address selection by the application for privacy addresses,
mobileipv6 addresses and Cryptographically
Some details:
..., CGA (cryptographically
generated addresses) and non-CGA addresses etc..
= you should note that CGAs are covered by some IPRs.
It is recommended that the application does a getsockopt() prior
= this comes only from the uncommon style (one
In your previous mail you wrote:
Le Vendredi 21 Mars 2003 00:39, Francis Dupont a écrit :
= you should avoid French in this list (:-).
It is expected that most applications should work fine without tuning the
= this is exactly the assumption I strongly disagree with.
source address
What I propose is to put the policy in the context of applications
(Unix user structure, environment, etc, even monitors have this kind
of things) so one can tune the address selection before launching
applications. When the context can be managed from applications
(the usual case), this
27 matches
Mail list logo
