About this list Date view Thread view Subject view Author view Attachment view

From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Thu 23 Oct 2003 - 00:11:34 BST

jack_at_solucorp.qc.ca (Jacques Gelinas) writes:

>> >> 1) set\control
>> > ...
>> > /proc should be used to do most of that.
>> No, it is a pain for userspace tools
>> ...
>> This /proc-parsing method requires a proc-filesystem also
> ...
> Not convincing. If /proc fails to open and deliver, I really doubt anything
> will work.

Real world example: in rpm-fake.so, the execve() LD_PRELOAD wrapper for
rpm-scriptlets is called from within a chroot. When I would trust in the
told values, an attacker could return e.g. the number of a noop syscall,
the context-change would succeed seemingly and the scriptlet runs in ctx

Most applications which are going into a chroot and changing the context
then, do not require /proc for their functionality but will fail since
they are relying on /proc.

And again; /proc parsing is ugly and error-prone.

>> > In the kernel, we only spit the various commands available and
>> > their version and userland tools can parse that. We keep the
>> > bload out of the kernel.
>> Implementing the parsing of 'set' commands would be much more
>> bloat IMO...
> I was talking about version number and get the list of functionnalities,
> not the set.

Sorry, I thought your statement was about the '1) set\control'
also. But a mandatory read-only /proc interface would be still more
bloat than a syscall-interface (I do not speak about the 10 line
change in /proc/self/status; you will have to create a new entry
with an own handler).

Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 23 Oct 2003 - 00:21:11 BST by hypermail 2.1.3