From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Thu 23 Oct 2003 - 00:14:09 BST
On Wed, 22 Oct 2003 19:03:05 -0500, Enrico Scholz wrote
> jack_at_solucorp.qc.ca (Jacques Gelinas) writes:
> >> 1) set\control
> >> 2) get info
> >> 3) get command version.
> > /proc should be used to do most of that.
> No, it is a pain for userspace tools to generate the control-commands
> and yet more pain to parse the results: there are lots of syscalls
> (open,read,close) involved (which can fail), buffer-sizes can not be
> determined in ahead, int->string and string->int conversions are
> needed, and the buffer itself must be parsed to get the position of
> the values.
> This /proc-parsing method requires a proc-filesystem also, which
> may be missing in chroots. Within vserver-chroots, /proc-parsing
> can make attacks possible when a /proc directory with malicious
> entries will be generated.
> Syscalls are *much* more agreeably for userspace-tools.
Not convincing. If /proc fails to open and deliver, I really doubt anything
will work. Unless you have a monitor program already running and ready
to perform vserver administration.
> > 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
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
Vserver mailing list