Messages in this thread | | | Subject | Re: CAP_SYSLOG, 2.6.38 and user space | From | Gergely Nagy <> | Date | Wed, 09 Feb 2011 23:37:19 +0100 |
| |
> what's wrong with doing a runtime test at startup that tries to read with > CAP_SYS_ADMIN and if you get -EPERM trying again with CAP_SYSLOG?
That's also an option I considered, and might end up doing if there's no easier option. In my case, though, due to the design of the code, it's not trivially simple to do that (it isn't particularly hard, either, but such a test wouldn't be my first choice).
> creating an ioctl for something like this seems like it's significantly > overcomplicating the issue.
True.
Nevertheless, like I said before: my main concern is making sure userspace doesn't break. Figuring out how to support CAP_SYSLOG best is a much lower priority on my list, and I haven't given it all that much thought.
I'd prefer an ioctl or something similar which I can easily query, without having to resort to trial and error or version sniffing. But I understand that's not the best option from a kernel PoV, so falling back to trying to read at startup is an acceptable solution aswell.
So, yeah... I suppose simply introducing CAP_SYSLOG, and keeping CAP_SYS_ADMIN as it is would work just fine.
-- |8]
| |