On Thu, 2012-08-02 at 16:26 -0400, Paul Moore wrote:
> On Thursday, August 02, 2012 09:42:06 PM Thiago Marcos P. Santos wrote:
> > On Thu, Aug 2, 2012 at 9:04 PM, Paul Moore <pmo...@redhat.com> wrote:
> > > On Thursday, August 02, 2012 06:36:49 PM tmpsan...@gmail.com wrote:
> > > >
> > > > It is always nice to provide this alternative version of variadic
> > > > functions since there is no portable way of wrapping them.
> > >
> > > Hmm, this would have been nice last week when I asked for any API
> > > changes.
> > > It doesn't mean we can't add it, just that the bar is a little bit higher
> > > now.
> > >
> > > I understand the basic why, but can you provide a concrete example of an
> > > application which needs this functionality?
> > >
> > > I'm also not sure about the new function names, I would like to keep the
> > > API "namespaced" with the "seccomp_" prefix ... maybe tack a "_va" on the
> > > end instead?
> > >
> >
> > I have a class called SeccompFilters. I want to keep the seccomp context
> > private and at the same time I want to let people add rules by using the
> > addRule() method. For that I would need something like the code bellow.
> >
> > void SeccompFilters::addRule(uint32_t action, int syscall, unsigned int...
> > {
> > va_list args;
> > va_start(args, arg_cnt);
> >
> >
> > int rc = seccomp_rule_add_va(m_context, action, syscall, arg_cnt,
> > args);
> > // error handling, failure is fatal
> >
> >
> > va_end(args);
> > }
> >
> > I'm tempted to handle every error when adding filters as fatal. People
> > willing to do the same, no matter if it is C or C++, can use the _va
> > functions to create a wrapper. C99 supports variadic macro, which might help
> > C developers, but doesn't solve my case because it could only be used inside
> > the class.
> >
> > #define seccomp_rule_add_or_crash(context, action, syscall, arg_cnt, ...) \
> > ASSERT(seccomp_rule_add(context, action, syscall, arg_cnt,
> > ##__VA_ARGS__) >= 0);
>
> First off, *please* no more HTML mail. I dislike having to remove the markup
> and reformat your email in my reply. It also has a tendency to make me
> cranky, and I'm less likely to apply patches when I'm cranky.
GMail web interface was forcing me to. I bet you kernel developers are
using mutt. If people stop using HTML, who will pay me to work on
WebKit? /me runs
> Anyway, back to the substance of your email ... Thanks for the example. In
> this particular case I think I would rather see us implement a structure
> which
> could be used to specify the arg/op/value combinations and pass a pointer to
> an array in the new rule_add APIs. The existing va_list based approach was
> designed to make it easier for developers by reducing the amount of work they
> had to do beyond just the function call, and while I think it succeeds for
> the
> most part, there are a lot of drawbacks around types and just safety in
> general. A structure based API removes many of these problems, and in your
> example shouldn't add too much burden to the developer.
>
> Thoughts?
It's a solution. But I also want to reduce the amount of work of people
using my class and my goal was to make the API resembling as much as
possible libseccomp. I don't want to suggest a change (actually an
addition and don't think it will break the ABI) based solely on my use
case. The code bellow repeats a lot on the tests and was also repeating
a lot on the examples.
rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(somesyscall), 0);
if (rc != 0)
return -1;
Adding the _va would allow people to "extend" the API themselves by
creating wrappers seccomp_rule_try_add_or_return, etc without falling
prey of preprocessor macros (something that with my C++ hat I'm always
trying to avoid).
> > If you are curious about for what purpose this code has being worked on:
> > https://bugs.webkit.org/show_bug.cgi?id=89875
>
> Cool, thanks for this. Are you targeting any specific browser, or just
> WebKit
> in general right now?
Every WebKit2 Linux port (EFL, GTK and Qt) and consecutively
browsers/webruntimes written on top of them will benefit from this work.
> > And I'm totally fine on changing the name. My original inspiration was the
> > [v]printf() family, but I guess it works for libc because they don't care
> > about namespace.
>
> Yeah, your logic does make sense, I just think there is value in keeping the
> API prefaced with a "seccomp_" to both help in identifying the library
> functions in other code and to ensure we don't collide with anything else.
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libseccomp-discuss mailing list
libseccomp-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
