[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 <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.
NO, it uses the setuid(2) system call, the setuid(2) call is only availible to
the super-user.
> I haven't looked at linux 'login' in detail, thus my example was not
> applicable to linux (but a valid example, nonetheless).
Yes, if we s/login/somesuidbin i agree completely.
> |> > |> 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.
Let me assure you, no su either :-)
~# ltrace -f -S -o login.trace login
[snip issue]
braindamage.linux.bogus login: root
Password:
There Aint No Such Thing As A Free Lunch
Last login: Tue Mar 9 04:41:01 on tty4.
No mail.
~# exit
logout
~# grep exec login.trace
731 execle(0x08054eb1, 0xbfffd3b4, 0, 0x08053b08, 0 <unfinished ...>
731 SYS_execve("/bin/bash", 0xbfffc37c, 0x08053b08) = 0
731 strcmp("enable", "exec") = -10
731 strcmp("eval", "exec") = -2
731 strcmp("exec", "exit") = -4
[snip many similar lines of parsing]
Sooo, NO su, no suid BUT setuid(2):
~# grep setuid login.trace
731 setuid(0 <unfinished ...>
731 SYS_setuid(0, 0xbfffd700, 0x4001ec2c, 0x40142d50, 0) = 0
731 <... setuid resumed> ) = 0
Yes, only root can run login. :-)
> |> > |>
> |> > |> > 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.
Ahh, hadn't thought of that. I usually telnet to wherever I want to debug.
> |>
> |> > |>
> |> > |> 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.
You have convinced me!
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