Re: mlock(2) for ordinary users

On Sat, 2006-Jul-22 18:16:31 +0300, Kostik Belousov wrote:
On Sat, Jul 22, 2006 at 03:52:37PM +0100, Robert Watson wrote:
particular, I have to wonder if it works at all. The whole idea of
resources limits is that you bill new use to a credential, and credit
reduced use to a similar credential.

Currently, most RLIMIT_xxx parameters are per-process (the exceptions
are RLIMIT_NPROC and RLIMIT_SBSIZE - which are per-user).

Probably, we're interested only in
memory pinned at the request of the process, not memory pinned by the
kernel on its behalf.

Should memory wired via sysctl_wire_old_buffer() count as "at the
request of the process" or "by the kernel on its behalf"? Currently,
it's treated as the former.

The following takes "credential" as "process" since that's how wired
memory is currently billed.

- When pages become locked on behalf of a credential, is it correctly billed
to the credential?

- When pages become unlocked (or are released), are any credentials that
have requested it be locked credited?

I believe these are true. This is the area where I'd appreciate assistance.

- What happens when the credential on a process changes between when memory
is locked and unlocked?

I don't think this is possible because the credential is a process.

- What happens if more than one credential requests the same page of memory
be locked and unlocked?

This is another area that would need further examination.

- Is locked memory properly credited back to the credential on process exit
and other non-explicit unmapping points?

Process exit is not relevant. I'm not sure about implicit unwiring.

As far as I remember, RLIMIT_MEMLOCK is per-process instead of per-cred.

It is.

As consequence, allowing mlock() for non-root users actually allow such
user to allocate value-of(RLIMIT_MEMLOCK) * value-of(RLIMIT_NPROC).

This is no different to the other per-process resource limits. On a
stock FreeBSD system, I can reach the system-wide FD limit with two
user processes. I can't see that having several processes each
locking RLIMIT_MEMLOCK pages provides any real benefit to the user
so this is really just another DoS vector.

In fact, I had to make the answers to the asked questions when I
implemented the per-user swap limits.

I didn't realise this existed. How do you control per-user swap? I
can't find any reference to this in either login.conf or setrlimit(2).

--
Peter Jeremy

Attachment: pgpxgwIjMNjdX.pgp
Description: PGP signature

Relevant Pages

  • Re: mlock(2) for ordinary users
    ... to allocate pinned memory pages to unprivileged processes. ... When pages become unlocked, are any credentials that ... resource limit implementations, the right credential needs to be credited. ... freed, we can credit the resources back to the original credential, not to ...
    (freebsd-arch)
  • Re: mlock(2) for ordinary users
    ... Whilst this is a valid concern, there are good security reasons for allowing a user to lock small amounts of memory to ensure that sensitive information don't wind up on swap devices. ... When pages become unlocked, are any credentials that have ... In the case of socket limits, for example, we actually keep a reference to the allocating credential in the struct socket so that when the socket is freed, we can credit the resources back to the original credential, not to the credential of whatever process last references the socket. ...
    (freebsd-arch)
  • Re: Read About Mark Seif
    ... Give credit where credit is due Hanks. ... psycho nut case. ... If you're going to list a man's credentials, ... On Oct 28 2007 9:15 AM, Paul Popinjay wrote: ...
    (rec.gambling.poker)