From: "Gix, Brian" <brian.gix@intel.com>
To: Michal Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>,
"Stotland, Inga" <inga.stotland@intel.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: RE: [PATCH BlueZ] mesh: Init keyring storage directory on node Attach()
Date: Thu, 18 Jul 2019 16:36:57 +0000 [thread overview]
Message-ID: <DEBB0CAA2616974FAE35E4B560B9A4376CBD3EA6@ORSMSX103.amr.corp.intel.com> (raw)
In-Reply-To: <20190718085923.4ljvk3t3avqdh24d@mlowasrzechonek2133>
Hi Inga, Michal,
> On 07/17, Inga Stotland wrote:
> >This adds initialization of keyring storage directory when a mesh node
> >is attached successfully.
> >---
> > mesh/node.c | 8 ++++++++
> >
> >+ /*
> >+ * TODO: For now always initialize directory for storing
> >+ * keyring info. Need to figure out what checks need
> >+ * to be performed to do this conditionally, i.e., presence of
> >+ * Provisioner interface, etc.
> >+ */
> >+ init_storage_dir(node);
>
> I think the keyring should be initialized as soon ad the node is created. The
> keyring should always exist, and should contain at least the local device key -
> otherwise DevKeySend can't be used to talk to local Config Server.
I agree that the keyring should probably always exist, but not really for the reason Michal states... There are no use case allowed in the specification that allows any Config Client except an authorized Provisioner to communicate with a Config Server (even the local Config Server)... Any changes to a nodes configuration states should be tracked by provisioners in a master database, and this is not really possible if any node is allowed to change it's own CFG Server states.
That said, A node can have configuration privileges *transferred* to it, and it is not the responsibility of the daemon to determine when this is. I am fine with creating an (empty) key ring for all nodes.... which in the current architecture just means a few empty folders.
>
> --
> Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
> Silvair http://silvair.com
> Jasnogórska 44, 31-358 Krakow, POLAND
next prev parent reply other threads:[~2019-07-18 16:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-18 4:01 [PATCH BlueZ] mesh: Init keyring storage directory on node Attach() Inga Stotland
2019-07-18 8:59 ` Michał Lowas-Rzechonek
2019-07-18 16:36 ` Gix, Brian [this message]
2019-07-18 18:54 ` Michal Lowas-Rzechonek
2019-07-18 17:08 ` Gix, Brian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DEBB0CAA2616974FAE35E4B560B9A4376CBD3EA6@ORSMSX103.amr.corp.intel.com \
--to=brian.gix@intel.com \
--cc=inga.stotland@intel.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=michal.lowas-rzechonek@silvair.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).