On 2023-07-28 13:52, James Carter wrote: > On Fri, Jul 28, 2023 at 9:29 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > On Thu, Jul 27, 2023 at 12:43 PM Juraj Marcin <juraj@xxxxxxxxxxxxxxx> wrote: > > > > > > On 2023-07-17 14:44, Stephen Smalley wrote: > > > > > > > > I'd be curious to see what results you would get if you simply added > > > > the new feature (prefix/suffix matching) without moving the name-based > > > > transitions into the avtab. > > > > > > Here are the performance metrics of a prototype solution, where the > > > filename transition key is extended with match_type and match is found > > > by shortening the name from the end or the beginning if a full match is > > > not found. > > > > > > [2] Reference kernel (447a5688005e), Fedora policy (format v33) > > > [3] This patchset, Fedora policy (format v33) > > > [4] This patchset, Fedora policy without prefix/suffix rules (format v34) > > > [5] This patchset, Fedora policy with prefix rules (format v34) > > > > > > > > > Test | Mem | Binary | Policy | Create tty | osbench > > > | Usage | policy | load | | create > > > | | size | time | (ms/file) | files > > > | (MiB) | (MiB) | (ms) | real | kernel | (us/file) > > > ------+-------+--------+--------+--------+--------+----------- > > > [2] | 157 | 3.4 | 76 | 1.256 | 0.871 | 9.4492 > > > [3] | 156 | 3.4 | 77 | 1.208 | 0.869 | 9.6160 > > > [4] | 157 | 3.4 | 71 | 1.239 | 0.893 | 9.6297 > > > [5] | 156 | 2.4 | 71 | 1.211 | 0.838 | 9.8305 > > > > This looks more promising to me - little-to-no impact on existing > > users with old policy/userspace, reduced memory usage once fully > > transitioned. Still some degradation in runtime for osbench but not > > sure what the variance/stddev is for those numbers. > > > > It does look promising. > > Does this new prototype change the kernel policy format and the userspace parts. > If it does, then I will go ahead and revert the previous userspace > patches and wait for the new ones. It does as I tried to keep the kernel policy format as close to the internal representation as possible. > > > > > Also wondering whether you considered the simpler approach of just > > > > augmenting the kernel to recognize and support use of wildcards at the > > > > beginning and/or end of the existing name field to signify a prefix or > > > > suffix match. That seems more amenable to extensions beyond just > > > > prefix or suffix match. > > > > > > I had not considered this approach in the beginning, but as I thought > > > about it, it did not seem as simple. > > > > > > For example, along with adding the wildcard character, we also need to > > > add the ability to escape it; otherwise, it would be a weird edge case > > > of an unsupported filename. Also, possibly to escape the escape > > > character itself. This adds more complexity to the solution. > > > > > > In addition to this, extending such solution to support wildcards > > > anywhere in the filename would also require reimplementing the filename > > > transitions structures or moving rules with wildcards away from current > > > filename transitions. Currently, the filename is part of the hashtab key > > > and prefix/suffix could work by checking all prefixes and suffixes of a > > > filename, which there are not that many. However, with a wildcard at any > > > position, this is not feasible. > > > > Fair enough. That said, I do wonder if users will immediately start > > asking for wildcards at any position, then file globbing or regexes, > > etc, and would like to allow for future extensibility in a less > > disruptive manner. > > If anyone knows of any cases where a prefix or suffix match would not > work, it would be nice to hear about those cases now. > Jim -- Juraj Marcin
