I've posted this to linux-net and netdev but have had no response. If there
is any confusion about what the bug is then just e-mail me for
clarification. If this is an intentional omission then could someone let me
know why.
Section 3.1.6 of RFC 2367 clearly indicates there are two
cases in which user space programs can send the kernel pfkey
'acquire' messages. The first case is just the 'struct sadb_msg'
header that should specify an error relating to a previous
acquire message. The second case is intended for use by routing
daemons and the like. This case is not implemented in the Linux
kernel - I have reprinted the relevant portion of the RFC below:
------------------
The third is where an application-layer consumer of security
associations (e.g. an OSPFv2 or RIPv2 daemon) needs a security
association.
Send an SADB_ACQUIRE message from a user process to the kernel.
<base, address(SD), (address(P),) (identity(SD),) (sensitivity,)
proposal>
The kernel returns an SADB_ACQUIRE message to registered sockets.
<base, address(SD), (address(P),) (identity(SD),) (sensitivity,)
proposal>
The user-level consumer waits for an SADB_UPDATE or SADB_ADD
message for its particular type, and then can use that
association by using SADB_GET messages.
----------
As one can see in net/key/af_key.c:pfkey_acquire() the only acquire messages
accepted are of format <base> and with errno != 0.
Now for the barrage of questions:
Was this omitted for a reason?
Are we aware this was omitted?
Does someone already have a patch?
Would a patch be accepted for 2.6.13 if it is sent in time?
This is a bug after all.
Cheers,
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |