[EMAIL PROTECTED] (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 0. 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). Enrico _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://www.solucorp.qc.ca/mailman/listinfo/vserver
