On Mon, 04 Feb 2002 18:46:36 PST, Chris Wright said: > as always, the lsm framework is agnostic. the error code is propagated > directly from the module's policy engine. it may be part of the > module's policy to return bogus error codes. in some cases this is not > well-supported by the surrounding kernel code. so in the case of > anthony's patch, a SIGBUS is what you'd get stuck with. The interesting part is that the program finds out there's a problem while doing a memory reference, *not* while issuing a syscall. Are there any *other* cases where a previously granted resource could be revoked, and the program can find out while NOT in a syscall? (For instance, you can read() a previously open()'ed fd and get EBADF or EINVAL if it's gone away - but that's an error on the syscall). Only other case I can think of is if sbrk()/brk()/malloc() and company do lazy allocation of backing store - AIX had a problem with getting a SIGSEGV with memory you *thought* you had gotten from malloc() but really hadn't, if swap space ran short before you actually touched the page.... No, I'm not asking if sbrk() is hooked by LSM - I'm asking what other resources could depart from a process and you find out asyncronously. Are there other similar gotcha's we need to worry about documenting? /Valdis
This archive was generated by hypermail 2b30 : Mon Feb 04 2002 - 19:18:29 PST