From owner-freebsd-hackers@freebsd.org Wed Aug 17 06:47:46 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 810FEBBD9E3; Wed, 17 Aug 2016 06:47:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 635001398; Wed, 17 Aug 2016 06:47:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from [10.0.1.11] (host109-151-51-95.range109-151.btcentralplus.com [109.151.51.95]) by cyrus.watson.org (Postfix) with ESMTPSA id A24BF46B89; Wed, 17 Aug 2016 02:47:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: How to bring au_to_attr(3) back to the userland? From: "Robert N. M. Watson" In-Reply-To: Date: Wed, 17 Aug 2016 07:47:38 +0100 Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org, Konrad Witaszczyk Content-Transfer-Encoding: quoted-printable Message-Id: <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> To: Mateusz Piotrowski <0mp@FreeBSD.org> X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 06:47:46 -0000 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