2 Feb 12:28
8 Feb 13:29
[PATCH 1/2] Define ENOAUTHSERVICE to indicate "Authentication service unavailable"
As the kernel has or will have filesystems (and possibly other services) that want to obtain authentication tokens and/or encryption data on demand (via GSSAPI for example), it would seem useful to provide an additional error code to indicate a problem with the lookup, rather than overloading some other error code. We already have EKEYREJECTED, EKEYREVOKED and EKEYEXPIRED to indicate problems with a token that we already have, but what if the authentication server just isn't available? Define ENOAUTHSERVICE to indicate "Authentication service unavailable". This can be used to indicate, for example, that an attempt was made by request_key() to retrieve a key, but the authentication server (e.g. a KDC) it is supposed to contact didn't answer or that it couldn't determine the location of a suitable server. One way this can be used is that the user of a network filesystem can get a TGT from the KDC and stash it in their session keyring, then the filesystem can attempt to automatically get a ticket for accessing the filesystem - but if the server is uncontactable then the ticket can be negatively instantiated with KEYCTL_REJECT, giving the error to be handed to future requests as ENOAUTHSERVICE and a small timeout so that the key will expire from the cache and allow a retry after a short while to prevent thrashing. Signed-off-by: David Howells <dhowells@...> --- arch/alpha/include/asm/errno.h | 1 + arch/mips/include/asm/errno.h | 1 + arch/parisc/include/asm/errno.h | 1 +(Continue reading)
8 Feb 13:29
[PATCH 2/2] Define ENONAMESERVICE and ENAMEUNKNOWN to indicate name service errors
Now that the kernel has filesystems (and possibly other services) that want to look up internet addresses corresponding to arbitrary hostnames retrieved from the server, it would seem useful to provide a couple of error codes to indicate problems with the look up, rather than overloading some other error code. Define ENONAMESERVICE to indicate "Network name service unavailable". This can be used to indicate, for example, that an attempt was made by dns_query() to make a query, but the name server (e.g. a DNS server) it is supposed to contact didn't answer or that it couldn't determine the location of a suitable server. Define ENAMEUNKNOWN to indicate "Network name unknown". This can be used to indicate, for example, that an attempt was made by dns_query() to make a query, but the name server (e.g. a DNS server) replied indicating that it had no matching records. The DNS query upcall program can report these to keyctl_reject() so that cached failed queries will respond with these errors until they expire. Signed-off-by: David Howells <dhowells@...> --- arch/alpha/include/asm/errno.h | 2 ++ arch/mips/include/asm/errno.h | 2 ++ arch/parisc/include/asm/errno.h | 2 ++ arch/sparc/include/asm/errno.h | 2 ++ include/asm-generic/errno.h | 2 ++ 5 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/alpha/include/asm/errno.h b/arch/alpha/include/asm/errno.h index 5edc21e..d6e8582 100644(Continue reading)
9 Feb 00:53
Re: [PATCH 1/2] Define ENOAUTHSERVICE to indicate "Authentication service unavailable"
On Wed, 08 Feb 2012 12:29:05 GMT, David Howells said: > +#define ENOAUTHSERVICE 139 /* Authentication service not available */ > > #define EHWPOISON 139 /* Memory page has hardware error */ Was this an intentional overload of 139 (and so on for other archs)? Just checking - I'm sure if it goes in like this, we'll see a patch to "fix" the collision for 3.16.0 or so... ;)
9 Feb 11:01
Re: [PATCH 1/2] Define ENOAUTHSERVICE to indicate "Authentication service unavailable"
Valdis.Kletnieks@... wrote: > Was this an intentional overload of 139 (and so on for other archs)? Just > checking - I'm sure if it goes in like this, we'll see a patch to "fix" the > collision for 3.16.0 or so... ;) Ummm... Odd... I'm surprised StGIT managed to reapply my patches with no warning. I'll fix the numbering in them. David
9 Feb 11:04
Re: [PATCH 2/2] Define ENONAMESERVICE and ENAMEUNKNOWN to indicate name service errors
Jim Rees <rees@...> wrote: > Define ENAMEUNKNOWN to indicate "Network name unknown". This can be used to > indicate, for example, that an attempt was made by dns_query() to make a query, > but the name server (e.g. a DNS server) replied indicating that it had no > matching records. > > Would this be the same as NXDOMAIN? That is, does it mean the name server > couldn't find a record, or does it mean that the record doesn't exist? Is there a way to tell the difference? Can you store a negative record in the DNS? Or is it that the DNS has records for the name, just not records of the type you're looking for (eg. NO_ADDRESS/NO_DATA from gethostbyname())? David
9 Feb 11:13
[PATCH 1/2] Define ENOAUTHSERVICE to indicate "Authentication service unavailable" [ver #2]
As the kernel has or will have filesystems (and possibly other services) that want to obtain authentication tokens and/or encryption data on demand (via GSSAPI for example), it would seem useful to provide an additional error code to indicate a problem with the lookup, rather than overloading some other error code. We already have EKEYREJECTED, EKEYREVOKED and EKEYEXPIRED to indicate problems with a token that we already have, but what if the authentication server just isn't available? Define ENOAUTHSERVICE to indicate "Authentication service unavailable". This can be used to indicate, for example, that an attempt was made by request_key() to retrieve a key, but the authentication server (e.g. a KDC) it is supposed to contact didn't answer or that it couldn't determine the location of a suitable server. One way this can be used is that the user of a network filesystem can get a TGT from the KDC and stash it in their session keyring, then the filesystem can attempt to automatically get a ticket for accessing the filesystem - but if the server is uncontactable then the ticket can be negatively instantiated with KEYCTL_REJECT, giving the error to be handed to future requests as ENOAUTHSERVICE and a small timeout so that the key will expire from the cache and allow a retry after a short while to prevent thrashing. Signed-off-by: David Howells <dhowells@...> --- arch/alpha/include/asm/errno.h | 2 ++ arch/mips/include/asm/errno.h | 1 + arch/parisc/include/asm/errno.h | 1 +(Continue reading)
9 Feb 14:44
Re: [PATCH 2/2] Define ENONAMESERVICE and ENAMEUNKNOWN to indicate name service errors
David Howells wrote: Jim Rees <rees@...> wrote: > Define ENAMEUNKNOWN to indicate "Network name unknown". This can be used to > indicate, for example, that an attempt was made by dns_query() to make a query, > but the name server (e.g. a DNS server) replied indicating that it had no > matching records. > > Would this be the same as NXDOMAIN? That is, does it mean the name server > couldn't find a record, or does it mean that the record doesn't exist? Is there a way to tell the difference? Can you store a negative record in the DNS? Or is it that the DNS has records for the name, just not records of the type you're looking for (eg. NO_ADDRESS/NO_DATA from gethostbyname())? It's an important distinction to the resolver if you want to avoid dns hijacking. See rfc2308. There doesn't seem to be a way to tell the difference from the gethostbyname call, which was designed before this was a problem. The on-the-wire dns query protocol does make the distinction. I suspect kernel dns clients won't need to know the difference, but I think it's useful if we decide on and document the meaning of the error codes. Maybe the answer is that ENAMEUNKNOWN means the same as a HOST_NOT_FOUND from gethostbyname().
10 Feb 15:04
[RFCv3] 0/10 af_unix: Multicast and filtering features on AF_UNIX
Hello, Following is an extension to AF_UNIX datagram and seqpacket sockets to support multicast communication. This is a result from a research we have been doing to improve the performance of the D-bus IPC system. The first approach was to create a new AF_DBUS socket address family and move the routing logic of the D-bus daemon to the kernel. The motivations behind and the thread of the patches post can be found in [1] and [2] respectively. The feedback was that having D-bus specific code in the kernel is a bad idea so the second approach was to implement multicast Unix domain sockets so clients can directly send messages to peers bypassing the D-bus daemon. A previous version of the patches was already posted [3] by Alban Crequy who also has a good explanation of the implementation on his blog [4]. The stable and development version of the patches can be pulled from [5] and [6] respectively. It is a work in progress so everything is still not working properly. We didn't want to send the full patches since we are more interested to discuss the proposed architecture and ABI rather than the kernel implementation (which can always be rework to meet upstream code quality). [1]http://alban-apinc.blogspot.com/2011/12/d-bus-in-kernel-faster.html [2]http://thread.gmane.org/gmane.linux.kernel/1040481 [3]http://thread.gmane.org/gmane.linux.network/178772 [4]http://alban-apinc.blogspot.com/2011/12/introducing-multicast-unix-sockets.html [5]http://cgit.collabora.com/git/user/javier/linux.git/log/?h=multicast-unix-socket-stable(Continue reading)
10 Feb 21:02
Re: [PATCH 2/2] Define ENONAMESERVICE and ENAMEUNKNOWN to indicate name service errors
Jim Rees <rees@...> wrote: > > Would this be the same as NXDOMAIN? That is, does it mean the name server > > couldn't find a record, or does it mean that the record doesn't exist? > > Is there a way to tell the difference? Can you store a negative record in > the DNS? Or is it that the DNS has records for the name, just not records > of the type you're looking for (eg. NO_ADDRESS/NO_DATA from > gethostbyname())? > > It's an important distinction to the resolver if you want to avoid dns > hijacking. See rfc2308. There doesn't seem to be a way to tell the > difference from the gethostbyname call, which was designed before this was a > problem. The on-the-wire dns query protocol does make the distinction. > > I suspect kernel dns clients won't need to know the difference, but I think > it's useful if we decide on and document the meaning of the error codes. > Maybe the answer is that ENAMEUNKNOWN means the same as a HOST_NOT_FOUND > from gethostbyname(). Should I propose an extra error code? Perhaps giving: ENONAMESERVICE "Network name service unavailable" ENAMEUNKNOWN "Network name not known" ENONAMERECORD "Network name query returned no records" Note that ENONAMESERVICE covers all of: not having a name service configured, not being able to contact the configured name server and the configured name server not being able to chain to the authoritative name server. However, I think this is probably okay.(Continue reading)
RSS Feed