Re: Reflection and /proc

[slurn@griffin.engr.sgi.com (Scott Lurndal)]

In article <7bk61t$afpq9@fido.engr.sgi.com>, you write:
|> 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..

how about a program which executes:

	fd = open("my_private_file", O_RDONLY, 0);
	system("exec /sbin/login");   

Or a shell script:

	#!/bin/ksh
	
	exec 15< my_private_file
	exec /sbin/login

Login must close all files that were open when it was invoked.

|> 
|> > 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...

That is why all login (and some inetd) programs have code similar to the following:

	for(i=3; i<getdtablesize(); i++)
		(void) close(i);

It would be much more efficient to just say:

	closeall(3);	/* Close 3 and higher */

|>  
|> 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.

And login _is_ suid, and therefore must be very careful in 
dealing with the environment _it_ inherits.

|>  
|> > 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?

'tis quite a bit more elegent and much easier to use.

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

Ptrace was never intended to control processes other than 
a single child process of a parent process.   Any extensions to
allow such control I believe are better handled through an 
SVR4-style /proc debugging interface.

|> 
|> > 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?

l10n and i18n mean different things to different people.   scratch
the l10n from my above statement, if to you it means localizing the
kernel for a specific locale rather than meaning adding the capability
to localize the kernel on a per-locale basis.


scott lurndal
silicon graphics, inc.		(i speak for myself)
-
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