Re: disable-cap-mlock

[William Lee Irwin III <wli@holomorphy.com>]

On Thu, Apr 01, 2004 at 10:34:25AM -0800, Andrew Morton wrote:
> What is the Oracle requirement in detail?
> If it's for access to hugetlbfs then there are the uid= and gid= mount
> options.
> If it's for access to SHM_HUGETLB then there was some discussion about
> extending the uid= thing to shm, but nothing happened.  This could be
> resurrected.
> If it's just generally for the ability to mlock lots of memory then
> RLIMIT_MEMLOCK would be preferable.  I don't see why we'd need the sysctl
> when `ulimit -m' is available?  (Where is that patch btw?)

I don't speak for Oracle (obviously), but it's basically for non-root
users to get at the stuff. There's an issue with a few pieces of
userspace that drive the kernel's capability bits being nonstandard
and/or broken (out-of-date? I can't even find the stuff).

DB2 gets away with using the C capability libraries directly because
its launcher scripts are basically setuid, then it arranges to avoid
dropping the capabilities. This is actually not ideal even for DB2, and
other databases don't use analogous launching scripts able to do this.

The "right" way from the userspace angle is basically either pam_cap or
the mlock rlimit, so when you log in as the database user, you get the
capabilities and/or rlimits. I don't appear to be able to decipher
what's going on with pam_cap and I'm not entirely sure anyone else has
either. The mlock rlimits appear to have a more coherent userspace
support story, and are "supposed" to be there anyway. The implementation
just seems to be missing pieces.


William Lee Irwin III <wli@holomorphy.com> wrote:
>> There are a couple of off-by-ones in there I've got fixes for below.

On Thu, Apr 01, 2004 at 10:34:25AM -0800, Andrew Morton wrote:
> Using the security framework is neat.  There are currently large spinlock
> contention problems in avc_has_perm_noaudit() which I suspect will make
> SELinux problematic in some server environments.  But I trust it is
> possible to disable SELinux in config while using Bill's security module?
> I guess we could live with sysctl which simply nukes CAP_IPC_LOCK, but it
> has to be the when-all-else-failed option, yes?

The module I wrote acts as one of a number of different alternative
security policies (choosable at compile-time, and even at runtime if
I'd figured out how to actually do loadable modules properly). The
entire callback infrastructure configures out, and choices of security
models configure each other out in turn. It's somewhat more general
than it has to be, and amounts to what's basically a semi-open security
model with the monotonic etc. properties of capabilities removed since
r/w fs access to /proc/sys/capabilities/* entails all others. In theory,
this could be used for other things (CAP_SYS_NICE and CAP_SYS_RAWIO
come to mind), though I'm not aware of any outcry for things like this
for any other capabilities but CAP_IPC_LOCK.

I guess I can say that I'm not actually very wild about the security
module I wrote myself (it was more of an isolation-from-the-core effort
than a thing I wanted in and of itself). Some pieces may be able to be
made safer for users with Steven's suggestions.


-- wli