On Fri, 15 Mar 2002 16:37:42 +0500
vlad <[EMAIL PROTECTED]> wrote:
> ������������
> ����� ������.
> � �������� �� RH6.2 ������ (2.2.20) ���� � ����������� �� ����
> ����������: ���� �� Openwall Project ow2
> ������ hap-linux-2.2.20-3.diff
> ����� �������� � ����� ����� oops �������� "������" ������ - �������
> ������ reset.
> �������� ������� ����� ������ oops-� 1.5.22 (�� ����� ����� 1.5.6)
> ��� �� ������. �������� ������������� oops ��� � ����� ����� (������
> ������ oops � ������ �������� ���) - ������ �� �������.
> ��� ����������?
���������� �� ����.
�� �������� ����� �� ��������� ������ ����� ����:
Enforce RLIMIT_NPROC on execve(2).
Linux lets you set a limit on how many processes a user can have, via a
setrlimit(2) call with RLIMIT_NPROC. Unfortunately, this limit is only
looked at when a new process is created on fork(2). If a process changes
its UID, it might exceed the limit for its new UID.
This is not a security issue by itself, as changing the UID is a privileged
operation. However, there're privileged programs that want to switch to a
user's context, including setting up some resource limits. The only fork(2)
required (if at all) is done before switching the UID, and thus doesn't
result in a check against RLIMIT_NPROC.
Enable this option to enforce RLIMIT_NPROC on execve(2) calls. (The Linux
2.0 version of this patch only checks the limit for processes that have
their "dumpable" flag reset, such as due to an UID change, to reduce the
performance impact.)
Note that there's at least one good reason I am not enforcing the limit
right after setuid(2) calls: some programs don't expect setuid(2) to fail
when running as root.
���
Destroy shared memory segments not in use.
Linux lets you set resource limits, including on how much memory a process
can consume, via setrlimit(2). Unfortunately, shared memory segments are
allowed to exist without association with any process, and thus might not
be counted against any resource limits.
This option automatically destroys shared memory segments when their attach
count becomes zero after a detach or a process termination. It will also
destroy segments that were created, but never attached to, on exit from the
process. (In case you're curious, the only use left for IPC_RMID is to
immediately destroy an unattached segment.)
Of course, this breaks the way things are defined, so some applications
might stop working. In particular, expect most commercial databases to
break. Apache and PostgreSQL are known to work, though. :-)
Note that this feature will do you no good unless you also configure your
resource limits (in particular, RLIMIT_AS and RLIMIT_NPROC). Most systems
don't need this.
������� ���������� �����.
������ glibc, berkleydb/gigabase, chroot ����������� ��� ���, �� ������ ������������
oops �����������
���������� ��������� oops �����
strace ./oops 2&>oops-debug
--
Konstantin N. Bezruchenko
BK5536-RIPE
=====================================================================
If you would like to unsubscribe from this list send message to
[EMAIL PROTECTED] with "unsubscribe oops" in message body.
Archive is accessible on http://lists.paco.net/oops-rus/
