Re: Reflection and /proc

[Erik Elmgren <erik.elmgren@swipnet.se>]

Quoting Scott Lurndal (slurn@griffin.engr.sgi.com):

> You've missed the point.  A process cannot know what file descriptors
> were in use prior to the fork() operation that created it.   Because 
> a login shell needs to start with a known environment, and because the
> shell will be started under a different uid than the root which the 
> login process is running under, login _must_ close all file descriptors
> before invoking the shell (leaving 0, 1 and 2) to avoid any overt
> channels (i.e. login probably has the shadow file open....).

A seriously broken login, seriously..

> Yes, speed is the concern.  With large systems running many users and 
> large databases, having to issue 2048 system calls on each login 
> can cause significant performance degradation.

You need to fix your login, fast...
 
Files are the responsibility of the opener. A closeall() would be usefull
for suid, maybe it should take a parameter telling "leave fds below this"
and maybe it should be mandatory for suid too.
 
> It is still possible.   Doing the debugger interface for /proc would
> be a bit of work, but on the bright side, it would eliminate the 
> monstrosity known as ptrace().
 
Either:
 
What's less monstrous with putting the same functionality in /proc?

Or:
 
What part of the ptrace functionality do you propose to remove?

> Who me?  Actually, most of the unix vendors have tried hard to 
> keep localization and internationalization concerns out of the
> kernel as much as possible (to the point where the standards 
> recommend that the characters representing file names be from the
> portable character set so they will be consistent across all
> locales).

Localization of the kernel wouldn't just be silly, it would be downright
stupid. Why? Ever heard of systems whith users from several countries?

Erik

--

Has it ever occurred to you that God might be a /committee/?
--- Jubal Harshaw
-
Linux-future: thinking about the future of the Linux kernel
Archive:      http://humbolt.nl.linux.org/lists/
Wish list:    http://users.ox.ac.uk/~mert0236/linux-future.html