linux-kernel - Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090617100057.2c505f1c@lxorguk.ukuu.org.uk>
Date:	Wed, 17 Jun 2009 10:00:57 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	David Howells <dhowells@...hat.com>
Cc:	dhowells@...hat.com, torvalds@...l.org, akpm@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-afs@...ts.infradead.org
Subject: Re: [PATCH 00/17] [RFC] AFS: Implement OpenAFS pioctls(version)s

> > Can you not put pioctl() into a C library linked with the openafs utilities
> > that generates more sensible interface calls?  I mean you have to produce
> > the pioctl() syscall wrapper anyway so why not make "pioctl" a user space
> > compat library?
> 
> pioctl() is almost implementable with a combination of (l)setxattr,
> (l)getxattr, set_key, keyctl_read, and if all else fails, open + ioctl or
> open(O_NOFOLLOW) + ioctl, but not quite completely.  There are things you can't
> open, even with O_NOFOLLOW.  And doing state-retaining setxattr/getxattr pairs
> is even more nasty than pioctl (IIRC, that's something Christoph suggested a
> while back).
> 
> Besides, I want a set of utilities that I can use in conjunction with both kAFS
> and OpenAFS without having to recompile.

"I want" isn't a good policy for the introduction of ugly as sin long
term interfaces into the kernel. Besides which you argument doesn't
actually make sense anyway.

If you have to put a pioctl() wrapper in a library then you can compile
both sets of tools with your wrapper library and the library can do the
relevant gunge to decide how to make the kernel calls and which ones to
make.

The pioctl() interface is crap, keep it in user space wrappers and put
actual proper structured interfaces into the kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/