[lkml]   [1999]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: User vs. Kernel (was: To be smug, or not to be smug, that is , the question)
MOLNAR Ingo writes:
> On Sat, 23 Jan 1999, Albert D. Cahalan wrote:

>>>> * Lack of generalized message passing
>>> (RT-signals in Linux, a feature of Linux 2.2)
>> Could user acahalan send 42 bytes to user mmuscovi?
> sure, 'mail mmuscovi < ./42bytefile'. What are you trying to
> achieve and why?

The original poster said "generalized message passing" and you
responded with something that can pass 4 or 8 bytes between
processes with the same UID. That isn't very general.

I'd be happy to see the doors patch in Linux 2.3, but perhaps
the original poster wanted the same kind of messages as Mach has.

>>>> * Lack of a decent privilege/capability model
>>> (i guess you missed include/linux/capability.h, a feature of 2.2.
>>> Not completely finished, but the main mechanizm is in there.)
>> I believe he means "true" capability support. In any case,
>> Linux can't revoke normal user capabilities.
> what do you mean by 'true'.

True capability systems are token-based. They work very much like
file descriptor security. Access can be passed from process to
process, but is not automatically shared by all processes with the
same UID. Capability fanatics don't care about filesystem security,
because they believe the filesystem namespace is one giant hole
that should be eliminated. Obviously this conflicts with POSIX,
but less extreme versions are commonly found in UNIX-like systems.
Data General's DG-UX supports true capabilities on files, and it
grants access only when all systems (DAC, MAC, CAC) allow it.
DG-UX is popular at hospitals and is rated B2 without the GUI.
(it still gets B1 with the GUI)

> what is 'user capabilities'.

Normal users can:

* Run a network server.
* Run a network client.
* Read files that are world-readable.
* Run setuid executables.
* Create files in directories they own.
* Create directories in directories they own.
* Make their own files world-readable.
* Create SysV shared memory
* Create SysV semaphores

We've often seen requests to deny users the ability to run a network
server, and sometimes seen requests to deny users the ability to run a
network client. I know I'd want to block SysV shared memory use if I
were running a server with crummy users.

>>>> * Blocking I/O
>>> (whats your problem with that?)
>> This limits concurrency. Within the kernel, IO events need not be
>> serialized. User-space can only get this ability with threads.
>> Threads are quite a bit of overhead for such a simple need, plus
>> the use of threads tends to promote bugs.
> take a look at async networking IO, fcntl(SETSIG), etc, implemented by
> Stephen Tweedie recently. (it's in 2.2)

Excellent - but only for network IO?

>>>> * Interruptible system calls
>>> (what is your point here)
>> It is not good to return to userspace, loop around, and make the system
>> call a second time. The overhead [...]
> Albert, do you have the slightest clue how often it happens to restart
> a system call, in a typical Linux system? Just for kicks, i've added
> a small hack to my kernel 5 minutes ago to count them:
> total syscalls: 28456
> restarted syscalls: 7
> what overhead exactly are you complaining about? ...

For 28456 calls, your apps had to test for a condition that
did not happen.

>> [...] and app code complexity are annoying.
> the application sees _nothing_ from a system call restart to
> begin with. It's handled in libc.

It was handled in libc 5, but that was not standards compliant.
Some apps need the system calls to be interrupted. The addition
of an alternate API could reduce that need. Standards compliant
apps could have the behavior they expect, while Linux-specific
apps could have more logical behavior.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [W:0.065 / U:14.396 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site