Picon

LOAN OFFER <at> 3% APPLY NOW.

E-mail us for an urgent loan today for more details.
David Howells | 22 Mar 14:35 2012
Picon

[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 could 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.

I envision that this error would primarily be generated by a kernel upcall for
the kernel to then pass back to the original userspace caller.  The kernel
itself might not actually pay any attention to it, except as a hint as to
whether to retry.

Signed-off-by: David Howells <dhowells@...>
(Continue reading)

David Howells | 22 Mar 14:35 2012
Picon

[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.

I envision that these errors would primarily be generated by a kernel upcall
for the kernel to then pass back to the original userspace caller.  The kernel
itself might not actually pay any attention to them, except as hints as to
whether to retry.

I have combined the NXDOMAIN and NODATA resolver errors into ENAMEUNKNOWN.  I'm
not sure whether it's worth separating them out.  I don't see the kernel really
needing to know the difference - if any optimised handling of NODATA is to be
done (say falling back from one DNS record type to another), I would expect
that to be done in the upcall rather than in the kernel.

However, it may be worth it from the point of view of reporting to the user.
(Continue reading)

Jann Horn | 27 Mar 15:29 2012

Why no flag to unlink a file on creation?

Hello,
I'm not too familiar with the internals of the kernel, so this question
might be stupid, and I'm not sure whether this is the right place to ask
about it, but anyway:
Why is there no flag for the "open" syscall to specify that you want the
file you're opening to be deleted? I think that it would be very useful
in combination with O_CREAT - you could create temporary files without
actually leaving files on the filesystem, given that the filesystem
supports it.

Jann Horn
Carlos O'Donell | 27 Mar 15:40 2012

Re: Why no flag to unlink a file on creation?

On Tue, Mar 27, 2012 at 9:29 AM, Jann Horn <jannhorn@...> wrote:
> Hello,
> I'm not too familiar with the internals of the kernel, so this question
> might be stupid, and I'm not sure whether this is the right place to ask
> about it, but anyway:
> Why is there no flag for the "open" syscall to specify that you want the
> file you're opening to be deleted? I think that it would be very useful
> in combination with O_CREAT - you could create temporary files without
> actually leaving files on the filesystem, given that the filesystem
> supports it.

The open() function behaviour is dictated both by POSIX and ISO C.

You really want to ask this on either the related C library mailing
list or the related POSIX standards group mailing list.

libc-help@... - The GNU C Library help mailing list.
* List for discussing GNU C Library issues and ISO C11 questions.
* http://www.gnu.org/software/libc/libc.html

or

austin-group-l@... - Austin Common Standards Revision List.
* List for discussing POSIX related issues
* http://www.opengroup.org/austin/lists.html

Cheers,
Carlos.

Gmane