[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reflection and /proc
Quoting Scott Lurndal (slurn@griffin.engr.sgi.com):
> 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");
Why would root want to run such a program??
> Or a shell script:
>
> #!/bin/ksh
>
> exec 15< my_private_file
> exec /sbin/login
Why would root want to run such a script??
> Login must close all files that were open when it was invoked.
Whomever opens a file should close it, or exec something that'll handle it.
> |>
> |> > 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 */
I agree, closeall(int highfd) could be usefull for suid programs.
> |>
> |> 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.
Huh?!
~$ ls -l `which login`
-rwxr-xr-x 1 root root 36780 Nov 16 00:52 /bin/login
Why is your login suid?? su is suid though. I've not been disagreeing because
I dislike the functionality, but because I didn't like the example... And the
functionality (which-fds-are-open) is in the kernel already, opendir and then
readdir on /proc/self/fds/ and close those you don't want..
> |>
> |> > 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.
It's easier to open() and read() or write() than ptrace()?! Or do you want to
write a debugger in sh? :-)
> |>
> |> 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.
Maybe I'm dense (entirely probable) but could you tell me _what's_ better?
> |> > 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.
I think we agree, what I was attacking was the idea that the kernels messages
should be localized. They should either be in English or be a message id.
Erik
--
Please tell me the errors of my ways so I might correct them.
-
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