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. > > > 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
