{"action":"created","issue":{"url":"https://api.github.com/repos/krb5/krb5/issues/375","repository_url":"https://api.github.com/repos/krb5/krb5","labels_url":"https://api.github.com/repos/krb5/krb5/issues/375/labels{/name}","comments_url":"https://api.github.com/repos/krb5/krb5/issues/375/comments","events_url":"https://api.github.com/repos/krb5/krb5/issues/375/events","html_url":"https://github.com/krb5/krb5/pull/375","id":123056200,"number":375,"title":"Kadmin set and extract keys with lockdown","user":{"login":"simo5","id":8332609,"avatar_url":"https://avatars.githubusercontent.com/u/8332609?v=3","gravatar_id":"","url":"https://api.github.com/users/simo5","html_url":"https://github.com/simo5","followers_url":"https://api.github.com/users/simo5/followers","following_url":"https://api.github.com/users/simo5/following{/other_user}","gists_url":"https://api.github.com/users/simo5/gists{/gist_id}","starred_url":"https://api.github.com/users/simo5/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/simo5/subscriptions","organizations_url":"https://api.github.com/users/simo5/orgs","repos_url":"https://api.github.com/users/simo5/repos","events_url":"https://api.github.com/users/simo5/events{/privacy}","received_events_url":"https://api.github.com/users/simo5/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-12-19T02:40:17Z","updated_at":"2016-02-04T21:31:35Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/krb5/krb5/pulls/375","html_url":"https://github.com/krb5/krb5/pull/375","diff_url":"https://github.com/krb5/krb5/pull/375.diff","patch_url":"https://github.com/krb5/krb5/pull/375.patch"},"body":"This patchset adds a number of features around key material in kdamin.\r\n1. A new setkey operation that allows to properly store salts.\r\n2. A new get_principal_keys operation protected by a new ACL_EXTRACT acl to retrieve stored keys\r\n3. A new principal attribute named KRB5_KDB_LOCKDOWN_KEYS that loks down keys and prevent\r\nany change or operation that would allow an admin to retrieve keys or set arbitrary keys including delete or renaming of a principal.\r\n\r\nAdditionally some tests have been added/modified to check these operations. "},"comment":{"url":"https://api.github.com/repos/krb5/krb5/issues/comments/180061161","html_url":"https://github.com/krb5/krb5/pull/375#issuecomment-180061161","issue_url":"https://api.github.com/repos/krb5/krb5/issues/375","id":180061161,"user":{"login":"greghudson","id":1131421,"avatar_url":"https://avatars.githubusercontent.com/u/1131421?v=3","gravatar_id":"","url":"https://api.github.com/users/greghudson","html_url":"https://github.com/greghudson","followers_url":"https://api.github.com/users/greghudson/followers","following_url":"https://api.github.com/users/greghudson/following{/other_user}","gists_url":"https://api.github.com/users/greghudson/gists{/gist_id}","starred_url":"https://api.github.com/users/greghudson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/greghudson/subscriptions","organizations_url":"https://api.github.com/users/greghudson/orgs","repos_url":"https://api.github.com/users/greghudson/repos","events_url":"https://api.github.com/users/greghudson/events{/privacy}","received_events_url":"https://api.github.com/users/greghudson/received_events","type":"User","site_admin":false},"created_at":"2016-02-04T21:31:35Z","updated_at":"2016-02-04T21:31:35Z","body":"Notes on the setkey_4 semantics:\r\n\r\n* It disallows n_key_data == 0, while the current setkey_3 does allow n_keys == 0.  While purgekeys is the normal way to discard all of the keys in a principal, I think we should probably allow n_key_data to be zero.\r\n\r\n* I don't think I had realized that we were only going to accept key data with identical kvno values.  If there's not a good reason for this restriction, I'm not sure we should have it.\r\n\r\n* When keepold is true, nothing seems to prevent adding keys with the same enctype and salttype as existing keys of the same kvno, even though we are check for duplicates within the keys being added.  I'm actually not sure what restrictions we want here.\r\n\r\n* We have a new requirement that key data be sorted in descending order by kvno.  We should call krb5_dbe_sort_key_data() after constructing the new key data to preserve this invariant.\r\n\r\n* I notice that chpass/chrand/cprinc sort the requested ks_tuple by the order in the principal's keysalt policy when one is set, while setkey_3 and setkey_4 do not sort the incoming keys that way.  Since it's a pre-existing problem, it's not strictly necessary that we fix it in this PR, but it seems like a shortcoming.\r\n\r\nAlso, make_ks_from_key_data() seems like the wrong helper function abstraction for this function.  The right abstraction would be one which checks the key data against the keysalt policy by folding in the call to apply_keysalt_policy()--or perhaps one which solves the above problem by re-sorting the incoming key data."}}