linux-kernel - Re: RFC: KEYS: Is this too-big a behavioural change for a system call?

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] [day] [month] [year] [list]

Message-ID: <CA+55aFxE+M54mSM7=nRP_frA7LDAQYyMW6UhcGq62hOP4bX5Kw@mail.gmail.com>
Date:	Thu, 30 Jan 2014 18:37:07 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Howells <dhowells@...hat.com>
Cc:	ghudson@....edu, simo@...hat.com, sgallagh@...hat.com,
	keys@...ux-nfs.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: RFC: KEYS: Is this too-big a behavioural change for a system call?

On Thu, Jan 30, 2014 at 9:03 AM, David Howells <dhowells@...hat.com> wrote:
>
> I've been asked by Kerberos developers to slightly change the behaviour of the
> add_key() and request_key() system calls and a couple of the keyctl() functions
> - and I'm wondering if you'd be okay with it.

So the rule about ABI changes has always been: "If somebody notices
it, we revert it".

IOW, it's not so much that you can't make changes, it's that you
cannot make changes that break programs.

And quite frankly, I have no good way to judge. Your (5) _sounds_
fair, but who knows what odd things some distributions do. We'd have
to be very careful, in *particular* we'd need to make it very very
clear to the krb people that if the change scews over any old users,
it gets reverted with extreme prejudice. At that point, maybe they say
"never mind, we might as well just always make sure we have a session
keyring".

And no, we are *not* going to say "we'll just stop doing this in the
kernel and expect pam_keyinit to do it for us".

But James' suggestion to perhaps have a new version of add_key() with
new semantics could work - if it's worth the pain (because we *would*
have to maintain the old interface basically forever, so it would be
more of a "the new system call doesn't really deprecate the old one,
it just has more convenient semantics").

          Linus
--
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/