From owner-trustedbsd-discuss@freebsd.org Mon Aug 15 22:37:30 2016 Return-Path: Delivered-To: trustedbsd-discuss@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 1B70FBB9586; Mon, 15 Aug 2016 22:37:30 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B438E150C; Mon, 15 Aug 2016 22:37:29 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-wm0-f65.google.com with SMTP id o80so13402728wme.0; Mon, 15 Aug 2016 15:37:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=js/dn0ARYNgBAO9nkckxOs9AVSSUkrrFAtu/8ngTw3U=; b=lYRsr9cQj5BZ0vrafeSQ620ypUc1pn3ZNiYNlIi7qH6Qd/NX2KGuTuOr/hpNkLdXdN X0Tx/KqDzKX22NyHoAIgXvM28HF8bkNMzXz0lNnqwm0YxlWeD9EO47ZdTmFin4BOjYOF ZcZYib7mM4IndVeWpxpFYpFsxAqeWje8FduTz4+vaC3Su7EpYUmtvxCwv+niOeU2H9RT zvyXD7FhQVDd9m0KxK623y3KJNM42cQm9LT4qRThZAbnU0kZObE1XNP7hf+4htVdZ2Yy i5LmQNsTKidXT6QTQILEHIxQ4ovzB6lZGk3snZ4DbLdgOePjhWtgNJC7TDT+o6hnyp7f Mu8Q== X-Gm-Message-State: AEkooutReWOIkKu/yRJDN3ipULfc8nWOXkbDYEmACWUAjFFm3VOLML0R6A/ocXJDMwRuNg== X-Received: by 10.28.113.151 with SMTP id d23mr18500003wmi.89.1471299522730; Mon, 15 Aug 2016 15:18:42 -0700 (PDT) Received: from maka.fritz.box (dslb-178-008-181-169.178.008.pools.vodafone-ip.de. [178.8.181.169]) by smtp.gmail.com with ESMTPSA id h7sm23547890wjd.17.2016.08.15.15.18.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Aug 2016 15:18:41 -0700 (PDT) From: Mateusz Piotrowski <0mp@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: How to bring au_to_attr(3) back to the userland? Date: Tue, 16 Aug 2016 00:18:40 +0200 Message-Id: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> Cc: Konrad Witaszczyk , rwatson@FreeBSD.org To: freebsd-hackers@freebsd.org, trustedbsd-audit@freebsd.org, trustedbsd-discuss@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 22:37:30 -0000 Hello, I participate in Google Summer of Code at FreeBSD this year. My project = is about converting Linux Audit logs to the BSM format (see my wiki[0]). Recently, I've come across a problem with the libbsm(3) API. I'd like to = be able to generate an attribute token. Unfortunatelly, au_to_attr which = generates those tokens is not available in the userland (I email FreeBSD-hackers at = FreeBSD about this issue[1]). Together with my mentor we came up with a few possible solutions to this = problem but we are not sure which one is the best. This is why I'd like to = dicuss the pros and cons. Solutions: 1. The first idea is to add a userland version of the au_to_attr = function. The implementation would be similar to the one of the au_to_exec_* = functions. (See sys/security/audit/bsm_token.c[2].) 2. The second idea is to bring back the vattr structure. At the moment au_to_attr has one paramter of type `struct vnode_au_info`. = Historically, au_to_attr used `struct vattr`. A possible solution is to bring vattr = to the userland and change the parameter of au_to_attr back to `struct vattr`. At the moment `struct vattr` is included in sys/vnode.h but it lacks = the interace. (I summed up everything I know on this wiki page[3].) 3. The last idea is to make `struct vnode_au_info` and `au_to_attr` = accessible from the userland (by simply unwrapping the prototypes from the = KERNEL/_KERNEL conditional compilation macros). Cheers, -Mateusz [0]: = https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools [1]: = https://lists.freebsd.org/pipermail/freebsd-hackers/2016-August/049835.htm= l [2]: = https://github.com/freebsd/freebsd/blob/af3e10e5a78d3af8cef6088748978c6c61= 2757f0/sys/security/audit/bsm_token.c#L1281-L1405 [3]: = https://github.com/0mp/freebsd/wiki/vattr(99://github.com/0mp/freebsd/wiki= /vattr(99) From owner-trustedbsd-discuss@freebsd.org Tue Aug 16 06:58:24 2016 Return-Path: Delivered-To: trustedbsd-discuss@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 81D95BBB0EF; Tue, 16 Aug 2016 06:58:24 +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 467FC1223; Tue, 16 Aug 2016 06:58:24 +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 0267846B43; Tue, 16 Aug 2016 02:58:22 -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: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> Date: Tue, 16 Aug 2016 07:58:22 +0100 Cc: freebsd-hackers@freebsd.org, trustedbsd-audit@freebsd.org, trustedbsd-discuss@freebsd.org, Konrad Witaszczyk Content-Transfer-Encoding: quoted-printable Message-Id: <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> To: Mateusz Piotrowski <0mp@FreeBSD.org> X-Mailer: Apple Mail (2.3124) X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 06:58:24 -0000 Hi Mateusz: I=E2=80=99m hear about your project =E2=80=94 a way to import Linux = audit records would be extremely useful to the community of BSM users = and tool writers. My memory is a bit hazy, but I believe the reason we did not stick with = Solaris=E2=80=99s API in this instance is that, in both Mac OS X and = FreeBSD, struct vattr is an in-kernel data structure that incorporates = kernel-internal data types, and is subject to (moderately frequent) = changes in a way that would disrupt the userspace ABI. In more recent = versions of Mac OS X, struct vattr has been replaced with struct = vfs_attr. The ideal choice would be to take the existing public data structure = describing file attributes (struct stat) and use that =E2=80=94 = unfortunately, not all of the fields we require (in particular the = filesystem ID) are present in the stat structure. I=E2=80=99m slightly unhappy with the name vnode_au_info, as although in = FreeBSD, Mac OS X, and Solaris, =E2=80=9Cvnode=E2=80=9D is the term = used, that=E2=80=99s not portable to Linux, where the term =E2=80=9Cinode=E2= =80=9D is used. We also want to avoid being almost but not quite API = compatible with the Solaris BSM API =E2=80=94 e.g., having an = au_to_attr(3) that takes a different pointer type is likely a recipe for = trouble. As a result, I feel a bit conflicted on the topic, but suspect the = easiest path is to rename vnode_au_info to struct au_vattr, and add a = new API au_to_vattr(3) that accepts a pointer to a new struct au_vattr = pointer. We would continue to not provide an au_to_attr symbol in the = OpenBSM libbsm. This would align us with the Solaris model, accepting = that it is a =E2=80=9Cvnode attribute token=E2=80=9D, but avoid = confusion about function signatures / prototypes / types. I think I=E2=80=99= d also re-craft struct au_vattr a bit to use the same types that are = present in the underlying token (e.g., uint32_t, =E2=80=A6) rather than = OS-local types (e.g., dev_t), in order to force consumers of the API to = cast to the BSM type, rather than having that occur transparently within = OpenBSM, which could cause information loss invisible to the caller = (they should do the information loss for us). Not sure you how you feel about that strategy? Robert > On 15 Aug 2016, at 23:18, Mateusz Piotrowski <0mp@FreeBSD.org> wrote: >=20 > Hello, >=20 > I participate in Google Summer of Code at FreeBSD this year. My = project is about > converting Linux Audit logs to the BSM format (see my wiki[0]). >=20 > Recently, I've come across a problem with the libbsm(3) API. I'd like = to be able > to generate an attribute token. Unfortunatelly, au_to_attr which = generates those > tokens is not available in the userland (I email FreeBSD-hackers at = FreeBSD > about this issue[1]). >=20 > Together with my mentor we came up with a few possible solutions to = this problem > but we are not sure which one is the best. This is why I'd like to = dicuss the > pros and cons. >=20 > Solutions: >=20 > 1. The first idea is to add a userland version of the au_to_attr = function. The > implementation would be similar to the one of the au_to_exec_* = functions. >=20 > (See sys/security/audit/bsm_token.c[2].) >=20 > 2. The second idea is to bring back the vattr structure. At the moment > au_to_attr has one paramter of type `struct vnode_au_info`. = Historically, > au_to_attr used `struct vattr`. A possible solution is to bring vattr = to the > userland and change the parameter of au_to_attr back to `struct = vattr`. >=20 > At the moment `struct vattr` is included in sys/vnode.h but it lacks = the > interace. >=20 > (I summed up everything I know on this wiki page[3].) >=20 > 3. The last idea is to make `struct vnode_au_info` and `au_to_attr` = accessible > from the userland (by simply unwrapping the prototypes from the = KERNEL/_KERNEL > conditional compilation macros). >=20 > Cheers, >=20 > -Mateusz >=20 > [0]: = https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools > [1]: = https://lists.freebsd.org/pipermail/freebsd-hackers/2016-August/049835.htm= l > [2]: = https://github.com/freebsd/freebsd/blob/af3e10e5a78d3af8cef6088748978c6c61= 2757f0/sys/security/audit/bsm_token.c#L1281-L1405 > [3]: = https://github.com/0mp/freebsd/wiki/vattr(99://github.com/0mp/freebsd/wiki= /vattr(99) >=20 From owner-trustedbsd-discuss@freebsd.org Tue Aug 16 23:18:21 2016 Return-Path: Delivered-To: trustedbsd-discuss@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 90640BBCBF3; Tue, 16 Aug 2016 23:18:21 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32C601C9A; Tue, 16 Aug 2016 23:18:20 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-wm0-f68.google.com with SMTP id i138so18986171wmf.3; Tue, 16 Aug 2016 16:18:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l87CpPKi8pUuB4kp8x3duVb6TRRFyH2CiF12sRrcdFA=; b=Ufo/Pa8xbGIOjzfdu7JQeZ/glqHewuTc6F13E44MIg9WUFPKEK3jokMtBKuF5eCl11 U6o49fpyfneVUrN3Q0lfTQypoxp4/kV/J/bHd0NGwDu6bCGKtI3qIx8EjPdw9cQaB+LE MC7U79U6KVX/1y7ObrE6EH5teuORyz9I7ftlC0VMX+0UfVkDXklPlVkNqzqG8aTsWsd8 BCPdjsixCk5/xlbSXayPr47Qd5sn3deUJo73osGq1jPlfSlw4XUNA1wqm9HG5AL7r5Uq 0UwvGIgGYNT9I6EE1cINhom+jc/HBxr1q+ZxmggskxebgPVQmmbsy+EoUsIJHEFUf8Ao 7nPg== X-Gm-Message-State: AEkoouvA1sVYIROr3N9+os3XnDJuHpH22CItsojD1T+8j8YHg3t/oyo3QZc/rVaarD5eqA== X-Received: by 10.25.210.75 with SMTP id j72mr6165112lfg.4.1471389492594; Tue, 16 Aug 2016 16:18:12 -0700 (PDT) Received: from [192.168.0.15] (87-207-152-10.dynamic.chello.pl. [87.207.152.10]) by smtp.gmail.com with ESMTPSA id 206sm1145084ljj.4.2016.08.16.16.18.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 16:18:11 -0700 (PDT) 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: Mateusz Piotrowski <0mp@FreeBSD.org> In-Reply-To: <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> Date: Wed, 17 Aug 2016 01:18:10 +0200 Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org, Konrad Witaszczyk Content-Transfer-Encoding: quoted-printable Message-Id: References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> To: "Robert N. M. Watson" X-Mailer: Apple Mail (2.3124) X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 23:18:21 -0000 Hello, On 16 Aug 2016, at 08:58, Robert N. M. Watson = wrote: >> On 15 Aug 2016, at 23:18, Mateusz Piotrowski <0mp@FreeBSD.org> wrote: >>=20 >> I participate in Google Summer of Code at FreeBSD this year. My = project is about >> converting Linux Audit logs to the BSM format (see my wiki[0]). >>=20 >> Recently, I've come across a problem with the libbsm(3) API. I'd like = to be able >> to generate an attribute token. Unfortunatelly, au_to_attr which = generates those >> tokens is not available in the userland (I email FreeBSD-hackers at = FreeBSD >> about this issue[1]). >>=20 >> Together with my mentor we came up with a few possible solutions to = this problem >> but we are not sure which one is the best. This is why I'd like to = dicuss the >> pros and cons. >>=20 >> Solutions: >>=20 >> 1. The first idea is to add a userland version of the au_to_attr = function. The >> implementation would be similar to the one of the au_to_exec_* = functions. >>=20 >> (See sys/security/audit/bsm_token.c[2].) >>=20 >> 2. The second idea is to bring back the vattr structure. At the = moment >> au_to_attr has one paramter of type `struct vnode_au_info`. = Historically, >> au_to_attr used `struct vattr`. A possible solution is to bring vattr = to the >> userland and change the parameter of au_to_attr back to `struct = vattr`. >>=20 >> At the moment `struct vattr` is included in sys/vnode.h but it lacks = the >> interace. >>=20 >> (I summed up everything I know on this wiki page[3].) >>=20 >> 3. The last idea is to make `struct vnode_au_info` and `au_to_attr` = accessible >> from the userland (by simply unwrapping the prototypes from the = KERNEL/_KERNEL >> conditional compilation macros). >>=20 >> [0]: = https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools >> [1]: = https://lists.freebsd.org/pipermail/freebsd-hackers/2016-August/049835.htm= l >> [2]: = https://github.com/freebsd/freebsd/blob/af3e10e5a78d3af8cef6088748978c6c61= 2757f0/sys/security/audit/bsm_token.c#L1281-L1405 >> [3]: = https://github.com/0mp/freebsd/wiki/vattr(99://github.com/0mp/freebsd/wiki= /vattr(99) >>=20 >=20 > I=E2=80=99m hear about your project =E2=80=94 a way to import Linux = audit records would be extremely useful to the community of BSM users = and tool writers. Thank you. It is really motivating to hear that after a couple of weeks = of starting=20 implementing the conversion over and over again. > My memory is a bit hazy, but I believe the reason we did not stick = with Solaris=E2=80=99s API in this instance is that, in both Mac OS X = and FreeBSD, struct vattr is an in-kernel data structure that = incorporates kernel-internal data types, and is subject to (moderately = frequent) changes in a way that would disrupt the userspace ABI. In more = recent versions of Mac OS X, struct vattr has been replaced with struct = vfs_attr. >=20 > The ideal choice would be to take the existing public data structure = describing file attributes (struct stat) and use that =E2=80=94 = unfortunately, not all of the fields we require (in particular the = filesystem ID) are present in the stat structure. This sounds like the best temporarily idea although the "au_vattr" plan = seems to be much=20 more reasonable to me. > I=E2=80=99m slightly unhappy with the name vnode_au_info, as although = in FreeBSD, Mac OS X, and Solaris, =E2=80=9Cvnode=E2=80=9D is the term = used, that=E2=80=99s not portable to Linux, where the term =E2=80=9Cinode=E2= =80=9D is used. We also want to avoid being almost but not quite API = compatible with the Solaris BSM API =E2=80=94 e.g., having an = au_to_attr(3) that takes a different pointer type is likely a recipe for = trouble. >=20 > As a result, I feel a bit conflicted on the topic, but suspect the = easiest path is to rename vnode_au_info to struct au_vattr, and add a = new API au_to_vattr(3) that accepts a pointer to a new struct au_vattr = pointer. We would continue to not provide an au_to_attr symbol in the = OpenBSM libbsm. This would align us with the Solaris model, accepting = that it is a =E2=80=9Cvnode attribute token=E2=80=9D, but avoid = confusion about function signatures / prototypes / types. I think I=E2=80=99= d also re-craft struct au_vattr a bit to use the same types that are = present in the underlying token (e.g., uint32_t, =E2=80=A6) rather than = OS-local types (e.g., dev_t), in order to force consumers of the API to = cast to the BSM type, rather than having that occur transparently within = OpenBSM, which could cause information loss invisible to the caller = (they should do the information loss for us). >=20 > Not sure you how you feel about that strategy? 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=20 attribute token. 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? 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. -Mateusz= From owner-trustedbsd-discuss@freebsd.org Wed Aug 17 06:47:46 2016 Return-Path: Delivered-To: trustedbsd-discuss@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: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: TrustedBSD General Discussion List 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