How to bring au_to_attr(3) back to the userland?

[Robert N. M. Watson]

On 17 Aug 2016, at 00:18, Mateusz Piotrowski <0mp at FreeBSD.org> wrote:

> To sum it up. The idea is to:
> 
> 1. Rename vnode_au_info to au_vattr.
> 2. Keep au_to_attr away from the userland.
> 3. Add au_to_vattr (the parameter of which is struct au_vattr) to the libbsm
> API and make it available to the userland.
> 4. Re-craft au_vattr to use the same types that are present in the underlying 
> attribute token.
> 
> I am not sure if I understand this properly; do we want to simply rename 
> vnode_au_info to au_vattr and make it available in the userland after a couple 
> of modifications? If so then it sounds like a good idea to me as long as I don't 
> break something accidentally. Wouldn't renaming and modifying struct vnode_au_info 
> cause compatibility problems and potentially break someone's software?

I guess you have two choices:

(1) Retain existing KPIs to slightly ease merging to FreeBSD and Mac OS X; they can adopt the new in-kernel interfaces when ready.

(2) Simply remove the old KPIs and consider it a feature.

The former probably does marginally ease merging the new OpenBSM version (one fewer kernel changes for FreeBSD and Mac OS X at the point of merge), so I see no harm in retaining it. However, as it’s ifdef’d _KERNEL || KERNEL in the OpenBSM header, it has not been exposed to user applications, just the kernel.

Remember that changes in these structures don’t affect the layout and interpretation of the tokens at all — it’s really just on the producer side that a KPI changes — and the information we’re able to expose.

The existing vnode_au_info isn’t really an appropriate public interface, so do make sure not to remove the ifdefs preventing its use — instead, we should focus on a new interface that is appropriate to be public by virtue of (a) having an appropriate struct type argument that has both the fields we require and is as non-OS-specific as possible; (b) doesn’t conflict with the current interface on FreeBSD/Mac OS X; and (c) doesn’t conflict with the current interface on Solaris.

> Apart from that it sounds like a reasonable solution.
> 
> Thank you very much for the detailed introduction to the complexity of this problem.
> Although the GSoC is coming to an end and I plan to focus on integrating my work
> into auditdistd, I hope to apply the solutions we discuss here sometime later.

The problems are all about compatibility, and I think we have a reasonable path here that does what we need without too much work.

Robert