From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935481AbcLOKRz convert rfc822-to-8bit (ORCPT ); Thu, 15 Dec 2016 05:17:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56184 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752252AbcLOKRw (ORCPT ); Thu, 15 Dec 2016 05:17:52 -0500 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <528b203d-ac72-e4a6-8517-e8c5c11055a4@gmail.com> To: mtk.manpages@gmail.com Cc: dhowells@redhat.com, keyrings@vger.kernel.org, linux-man , Eugene Syromyatnikov , lkml Subject: Re: Revised request_key(2) man page for review MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Date: Thu, 15 Dec 2016 10:10:56 +0000 Message-ID: <23323.1481796656@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 15 Dec 2016 10:10:58 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michael Kerrisk (man-pages) wrote: > > │Is 'keyring' allowed to be 0? Reading the source, it │ > > │appears so. In this case, by default, the key is │ > > │assigned to the session keyring. But, the │ > > │KEYCTL_SET_REQKEY_KEYRING also seems to have an │ > > │influence here. What are the details here? │ Yes, the destination keyring can be 0. If you don't specify a destination keyring, then: (1) If the key is found to already exist, the serial number is returned, but no extra link is made. (2) If an error occurs other than "this key doesn't exist", then you'll just get the error. (3) If we have to construct a new key, this will be attached to the default keyring (as there's no destination keyring to attach to). > > # echo 'create user mtk:* * /bin/keyctl instantiate %k %c %S' \ > > > /etc/request-keys.conf There's a /etc/request-keys.d/ directory now. David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: Revised request_key(2) man page for review Date: Thu, 15 Dec 2016 10:10:56 +0000 Message-ID: <23323.1481796656@warthog.procyon.org.uk> References: <528b203d-ac72-e4a6-8517-e8c5c11055a4@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, keyrings-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-man , Eugene Syromyatnikov , lkml List-Id: linux-man@vger.kernel.org Michael Kerrisk (man-pages) wrote: > > │Is 'keyring' allowed to be 0? Reading the source, it │ > > │appears so. In this case, by default, the key is │ > > │assigned to the session keyring. But, the │ > > │KEYCTL_SET_REQKEY_KEYRING also seems to have an │ > > │influence here. What are the details here? │ Yes, the destination keyring can be 0. If you don't specify a destination keyring, then: (1) If the key is found to already exist, the serial number is returned, but no extra link is made. (2) If an error occurs other than "this key doesn't exist", then you'll just get the error. (3) If we have to construct a new key, this will be attached to the default keyring (as there's no destination keyring to attach to). > > # echo 'create user mtk:* * /bin/keyctl instantiate %k %c %S' \ > > > /etc/request-keys.conf There's a /etc/request-keys.d/ directory now. David -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html