2014-01-27 Lennart Poettering <lenn...@poettering.net>: > On Sat, 25.01.14 18:06, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: > >> > Doesn't libseccomp provide a way to enumerate the contents of the >> > defined filter again? I'd really prefer if we could find a way that >> > specifiying a filter of "read write" and of "write read" would actually >> > result in the same string exposed via the bus. >> Unfortunately no, this is why I strdup the string from the .service, >> but yes I see why this is not really a good idea... >> >> Maybe by adding each syscall, after being validated by the libseccomp >> API, in an array and sorting them ? And if the first element is the ~ >> then it's a blacklist ? > > Yeah, so I would be fine with parsing the string and resolving the > syscalls with seccomp_syscall_resolve_name(), then adding the returned > integer to an array, then sort the array and regenerate a string out if > it again with seccomp_syscall_resolve_num(), possibly prefixing it with > "~"... That way, we'd expose a string, but a normalized and somewhat > portable one. > I have an issue about a specific detail in the documentation of SystemCallFilter : "This option may be specified more than once in which case the filter masks are merged"
There is no problem if someone do something like: SystemCallFilter=write read execve SystemCallFilter=ioperm -- or -- SystemCallFilter=~write read execve SystemCallFilter=~ioperm But in a case like: SystemCallFilter=~write read execve SystemCallFilter=ioperm What about ioperm ? Should it be considered like ~ioperm ? If yes what happen if someone do something like this: SystemCallFilter=write read execve SystemCallFilter=~ioperm Should we ignore the ~ioperm and generate an error ? or something else ? Since it doesn't mean anything. I mention this because I was about to send the new patch but I noticed that in the previous patch and the new one I forgot about this part in the documentation. > Lennart > > -- > Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel