On Thu, Oct 31, 2019 at 10:51 AM Steve Grubb [off-list ref] wrote:

On Wednesday, October 30, 2019 6:03:20 PM EDT Richard Guy Briggs wrote:

quoted

quoted

Also, for the record, removing the audit loginuid from procfs is not
something to take lightly, if at all; like it or not, it's part of the
kernel API.

It can also be used by tools to iterate processes related to one user or
session. I use this in my Intrusion Prevention System which will land in
audit user space at some point in the future.

Let's try to stay focused on the audit container ID functionality; I
fear if we start bringing in other unrelated issues we are never going
to land these patches.

quoted

Oh, I'm quite aware of how important this change is and it was discussed
with Steve Grubb who saw the concern and value of considering such a
disruptive change.

Actually, I advocated for syscall. I think the gist of Eric's idea was that /
proc is the intersection of many nasty problems. By relying on it, you can't
simplify the API to reduce the complexity.

I guess complexity is relative in a sense, but reading and writing a
number from a file in procfs seems awfully simple to me.

Almost no program actually needs
access to /proc. ps does. But almost everything else is happy without it. For
example, when you setup chroot jails, you may have to add /dev/random or /
dev/null, but almost never /proc. What does force you to add /proc is any
entry point daemon like sshd because it needs to set the loginuid. If we
switch away from /proc, then sshd or crond will no longer /require/ procfs to
be available which again simplifies the system design.

It's not that simple, there are plenty of container use cases beyond
ps which require procfs:

Most LSM aware applications require procfs to view and manage some LSM
state (e.g. /proc/self/attr).

System containers, containers that run their own init/systemd/etc.,
require a working procfs.

Nested container orchestrators often run in system containers, which
require a working procfs (see above).

I'm sure there are plenty others, but these are the ones that came
immediately to mind.

-- 
paul moore
www.paul-moore.com