Date: Fri, 23 Sep 2016 12:09:30 +0200 From: Konrad Witaszczyk <def@FreeBSD.org> To: "Robert N. M. Watson" <rwatson@FreeBSD.org>, Mateusz Piotrowski <0mp@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org Subject: Re: How to bring au_to_attr(3) back to the userland? Message-ID: <08154690-df05-9314-702e-4e0cdd661f04@FreeBSD.org> In-Reply-To: <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> <C3FCD083-9DB0-43CA-8C68-A4CCE3BB6636@FreeBSD.org> <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tqie9SOJmMNO0r42m8w0uJ24GwhGngFil Content-Type: multipart/mixed; boundary="QhWplOJG4rl41lSBCn4LIBfPPjGLtLTmM"; protected-headers="v1" From: Konrad Witaszczyk <def@FreeBSD.org> To: "Robert N. M. Watson" <rwatson@FreeBSD.org>, Mateusz Piotrowski <0mp@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org Message-ID: <08154690-df05-9314-702e-4e0cdd661f04@FreeBSD.org> Subject: Re: How to bring au_to_attr(3) back to the userland? References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> <C3FCD083-9DB0-43CA-8C68-A4CCE3BB6636@FreeBSD.org> <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> In-Reply-To: <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> --QhWplOJG4rl41lSBCn4LIBfPPjGLtLTmM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/17/2016 08:47, Robert N. M. Watson wrote: > 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 und= erlying=20 >> attribute token. >> >> I am not sure if I understand this properly; do we want to simply rena= me=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 v= node_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. I think it won't be hard to adopt the changes in the FreeBSD kernel toget= her with the changes in libbsm. Would you still consider it as an issue becau= se of macOS if we fix it in FreeBSD? I don't know how important it is to their developers to stick with the current OpenBSM implementation. > (2) Simply remove the old KPIs and consider it a feature. > > The former probably does marginally ease merging the new OpenBSM versio= n (one fewer kernel changes for FreeBSD and Mac OS X at the point of merg= e), 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 layo= ut 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 informatio= n we=E2=80=99re able to expose. > > The existing vnode_au_info isn=E2=80=99t really an appropriate public i= nterface, 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 th= at 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 Solari= s. > >> 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 integrati= ng my work >> into auditdistd, I hope to apply the solutions we discuss here sometim= e later. > The problems are all about compatibility, and I think we have a reasona= ble path here that does what we need without too much work. > > Robert > --QhWplOJG4rl41lSBCn4LIBfPPjGLtLTmM-- --tqie9SOJmMNO0r42m8w0uJ24GwhGngFil Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJX5P9bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGREI1MzAxNjZGNTBCM0NCRUQ5QjZGNzdF MUMxMjI1QjBCMjZBNEYwAAoJEOHBIlsLJqTwzEIQAKAf2csdzjrIBYmEejXXoUxA 1e1mSyxeDQDNrWvk2xBpfkDsGgJubR7WCpJhm8u7T85D/Dg34e4YYHsuCevMdOEt DVg+cPskSSv/ZE16VYelcUI6lZCJqhB7rsi6E4nislXMVhqUzh4+CxnpOwCrNc5b xaTSYkex/rUFQJosMDM0bHHSep3Nc9a9sBSIaTnZpUemIQYKZPBRYd9TvOlrTWqd 60sMZJBdqyiVPus3boe29kPjrJLRL+LOdJxLyP8/a8/LQUT0DFjn/SHj10UDyWtw jS8LB+eDku0ckMNJtZ9RC8mQ/z0Lp6tDjdPfVwINgtpi82pcUafLgwno5gk4oujE 1/AQWIhKbTdcahA3WivS0AJqYaxk9JZAfTSLyPicmKWCY5Qugt/x3sjfDpjjoNQ6 xE1Ahs4GZTZy8T2bEWB4ZjqxzNBYX3+KvGNvAI+2HhTRWod9XOLZasutgj+zBNGi 8p4zTOTqTWMXPYnDr6Xfw1PwCslLiZVVpWNx75wvuQNss3kUCI9/52iVQZ/9TPAm Mo7R0Egu5Dz6VfwkarxE8bjKiHbqzTbjxSiDuaoUUzbLnYMlQwRWgFwKNyUTvTRD raIgjDAGQQ+ZGbZHUgSRdgy+qR8NBzOa0g2uRicxhZRDrss/sbNEwFTQyOwBGDp4 M7AEV/WF4xdXH9ksejng =NKx4 -----END PGP SIGNATURE----- --tqie9SOJmMNO0r42m8w0uJ24GwhGngFil--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08154690-df05-9314-702e-4e0cdd661f04>