On 2019-10-31 10:50, Steve Grubb wrote:

Hello,

TLDR;  I see a lot of benefit to switching away from procfs for setting auid & 
sessionid.

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.

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. 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.

quoted

Removing proc support for auid/ses would be a
long-term deprecation if accepted.

It might need to just be turned into readonly for a while. But then again, 
perhaps auid and session should be part of /proc/<pid>/status? Maybe this can 
be done independently and ahead of the container work so there is a migration 
path for things that read auid or session. TBH, maybe this should have been 
done from the beginning.

How about making loginuid/contid/capcontid writable only via netlink but
still provide the /proc interface for reading?  Deprecation of proc can
be left as a decision for later.  This way sshd/crond/getty don't need
/proc, but the info is still there for tools that want to read it.

-Steve

- RGB