On Mon, Jul 8, 2019 at 2:12 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > On 2019-05-30 19:26, Paul Moore wrote: ... > > I like the creativity, but I worry that at some point these > > limitations are going to be raised (limits have a funny way of doing > > that over time) and we will be in trouble. I say "trouble" because I > > want to be able to quickly do an audit container ID comparison and > > we're going to pay a penalty for these larger values (we'll need this > > when we add multiple auditd support and the requisite record routing). > > > > Thinking about this makes me also realize we probably need to think a > > bit longer about audit container ID conflicts between orchestrators. > > Right now we just take the value that is given to us by the > > orchestrator, but if we want to allow multiple container orchestrators > > to work without some form of cooperation in userspace (I think we have > > to assume the orchestrators will not talk to each other) we likely > > need to have some way to block reuse of an audit container ID. We > > would either need to prevent the orchestrator from explicitly setting > > an audit container ID to a currently in use value, or instead generate > > the audit container ID in the kernel upon an event triggered by the > > orchestrator (e.g. a write to a /proc file). I suspect we should > > start looking at the idr code, I think we will need to make use of it. > > To address this, I'd suggest that it is enforced to only allow the > setting of descendants and to maintain a master list of audit container > identifiers (with a hash table if necessary later) that includes the > container owner. We're discussing the audit container ID management policy elsewhere in this thread so I won't comment on that here, but I did want to say that we will likely need something better than a simple list of audit container IDs from the start. It's common for systems to have thousands of containers now (or multiple thousands), which tells me that a list is a poor choice. You mentioned a hash table, so I would suggest starting with that over the list for the initial patchset. -- paul moore www.paul-moore.com
