Re: Merging into the LSM: handling /proc

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

From: Chris Wright (
Date: Wed Oct 24 2001 - 12:18:55 EDT

* Jacques Gelinas ( wrote:
> I have looked at the LSM and it seems to be the thing we need (and
> potentially a thing I need to complete my virtualfs
> project)


> In some case, it would be useful to allow override
> int done = 0;
> ret = security-hooks (&done,...);
> if (!ret && !done){
> ...
> }

this sounds like an age old debate we've had in LSM, but i'd like to
make sure i understand. is 'done' a saved error state? if not, what is

> This seems like featurism for the security module, but this can be an issue
> for the vserver project. For example, the current kernel patch provides
> a per vserver hostname. This is probably doable in user space (modifying
> glibc somewhat maybe), but might not be as robust. Several utilities
> relies on the hostname to initialise some default. We want vserver to
> be as real as possible.

while not pretty, with small syscalls like sys_newuname, you can always
simply capture the syscall and handle it yourself. i believe with the
current implementation your results will vary, based on syscall used.
sys_uname, sys_newuname, sys_gethostname, sys_getdomainname don't look
like they'll give the user consistent information.

> The vserver patch provides a modified view of the processes in /proc. How
> can this be build right now ?.

/proc entries can be protected via open. the information you add to the
/proc entry isn't possible without either a patch, or a new entry that
is vserver specific (e.g. /proc/vserver).


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

This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:00 EDT