On 02/27/2016 04:06 PM, Ralf Mardorf wrote:
> #<domain> <type> <item> <value>
> @foo soft nproc 20
> @foo hard nproc 50
>
> Every user who is _not_ in the group "foo", simply is _not_ in
> this group, it makes completely no sense to introduce a negation of
> being in a group, since the negation is already not being member of this
> group.
The short explanation here is "complexity and design decisions". The
naive approach is probably to check for negations first, and skip the
line if a user is in a negated group. The application of a rule to all
except those in a group is a form of that: negation, all.
The bigger question is what purpose does this serve? Limits are not so
much a security feature as an administrative resource feature, and
they're flaky as hell. They're set by a privileged process (such as
login) and inherited by children. That's why MySQL or Apache can start
up, set their own ulimit (as root), and then drop privileges and switch
to the mysql or www-data user and keep their limits: no interposing
process makes any further decisions.
The general limit of "don't create 80,000 processes" stops fork bombs;
everything else is academic. Even then, it just stops :(){ :|:; } and
not a thread-creating perl script.
I use limits to keep those little boxes around and make sure my system
behaves in cases where it's being erratic. When it's under attack,
ulimits don't really offer any considerable protection. They're part of
a list of pointless security dogma, like running chmod go= on mount,
ping, and other setuid binaries. Everyone wants a checklist so they can
claim they've "hardened" their system without actually bothering to
identify threats and set up things like network-level firewalling,
privilege separation, and the like.
It's the same reason people encrypt data in databases with the key
stored in the application config file or, as with Miva Merchant, in the
"AESKey" column right next to the encrypted credit card numbers: "It's
encrypted and encryption is security!"
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
