[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: How to bring au_to_attr(3) back to the userland?
From:       "Robert N. M. Watson" <rwatson () FreeBSD ! org>
Date:       2016-08-17 6:47:38
Message-ID: 93122C2D-A660-4A47-A780-44E8309E4377 () FreeBSD ! org
[Download RAW message or body]

On 17 Aug 2016, at 00:18, Mateusz Piotrowski <0mp@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

_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


[prev in list] [next in list] [prev in thread] [next in thread]