Date: Wed, 17 Aug 2016 07:47:38 +0100 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Mateusz Piotrowski <0mp@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org, Konrad Witaszczyk <def@freebsd.org> Subject: Re: How to bring au_to_attr(3) back to the userland? Message-ID: <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> In-Reply-To: <C3FCD083-9DB0-43CA-8C68-A4CCE3BB6636@FreeBSD.org> References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> <C3FCD083-9DB0-43CA-8C68-A4CCE3BB6636@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 Aug 2016, at 00:18, Mateusz Piotrowski <0mp@FreeBSD.org> wrote: > To sum it up. The idea is to: >=20 > 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=20 > attribute token. >=20 > I am not sure if I understand this properly; do we want to simply = rename=20 > vnode_au_info to au_vattr and make it available in the userland after = a couple=20 > of modifications? If so then it sounds like a good idea to me as long = as I don't=20 > break something accidentally. Wouldn't renaming and modifying struct = vnode_au_info=20 > 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=E2=80=99s = ifdef=E2=80=99d _KERNEL || KERNEL in the OpenBSM header, it has not been = exposed to user applications, just the kernel. Remember that changes in these structures don=E2=80=99t affect the = layout and interpretation of the tokens at all =E2=80=94 it=E2=80=99s = really just on the producer side that a KPI changes =E2=80=94 and the = information we=E2=80=99re able to expose. The existing vnode_au_info isn=E2=80=99t really an appropriate public = interface, so do make sure not to remove the ifdefs preventing its use = =E2=80=94 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=E2=80=99t conflict with the = current interface on FreeBSD/Mac OS X; and (c) doesn=E2=80=99t conflict = with the current interface on Solaris. > Apart from that it sounds like a reasonable solution. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93122C2D-A660-4A47-A780-44E8309E4377>