[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reflection and /proc
In article <7bs6oj$becth@fido.engr.sgi.com>, you write:
|> 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??
It appears that linux is subtley different in the way that
login works. In SVR4 derived systems such as Irix, or Unixware,
$ ls -lL /usr/bin/login
-rwsr-xr-x 1 root sys 65848 May 22 1998 /usr/bin/login
It is /usr/bin/login (or more specifically, /usr/lib/iaf/scheme) which
handles the login process starting at reading and validating the password
through executing the login shell. At some point in this process,
login must change it's uid to that of the new user; thus it is setuid.
I haven't looked at linux 'login' in detail, thus my example was not
applicable to linux (but a valid example, nonetheless).
|> > |>
|> > |> 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..
|>
So, it would appear that linux login just invokes su, whereas other
unices login perform equivalent functionality as setuid applications.
|> > |>
|> > |> > 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? :-)
One advantage of the SVR4.2MP version of /proc is that it allows
the debugger to control the debugged process over NFS or any other
distributed file system. This functionality has in the past been useful to me.
|>
|> > |>
|> > |> 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?
Where shall we start? ptrace() was designed to work with a single
parent-child relationship, while /proc was designed to allow multiple
processes and/or threads to be controlled by a single debugger; without
imposing relationship constraints on the debugger (note the crufty stuff
to reparent a process temporarily in linux to support the ptrace extensions).
ptrace() relies on signals to both carry data and indicate events
of interest to the debugger. Note that there are many problems with
signals which can cause the debugger to be more complex than necessary,
chiefly that multiple signals can be combined into a single delivery
by the kernel. /proc uses an asynchronous control mechanism to control
the target process, and uses blocking reads (and/or poll(2)/select(2)) to
allow the debugger to wait for specific events.
ptrace() was never designed to provide a mechanism to allow a debugger
to control and manipulate a multithreaded process (with associated
kernel-level schedulable entities), /proc was and does (as of SVR4.2MP).
I also believe that /proc is more naturally extensible than ptrace
is (more from the kernel point of view, than from a feature or
application point of view); a factor which has led to the (ab)use
of /proc to catalog the hardware inventory, etc.
|> > 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.
|>
Agreed.
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