> We should be very careful about changing this. But if we change it
> only for the actual term program, it might be harmless.
Yes, I was only talking about term's virtual node, and not transmitting the
changes to the underlying node on disk so it could be abused. Even so, I
think the thing to d
Roland McGrath <[EMAIL PROTECTED]> writes:
> > More exactly, you mean before calling proc_setowner.
>
> Yes.
>
> > We should be more careful here.
>
> How?
As I described below. :)
> > For all we know, we have big giant hairy port leaks in the startup code
> > for the Hurd, and every proces
Roland McGrath <[EMAIL PROTECTED]> writes:
> So login only needs to be setuid if you aren't using the password server,
> in theory. The things that are failing are proc_setowner and chown called
> before the exec. Those are using the old proc and auth state rather than
> the state that is being
> You mean auth_makeauth inside ugids_verify_make_auth, right?
Sure.
> Without being root, login makes ids of new user.
Oh, yeah. I never really paid attention to the password server.
So login only needs to be setuid if you aren't using the password server,
in theory. The things that are fail
Roland McGrath wrote:
auth_makeauth will fail when the caller is authenticated as nonroot.
You mean auth_makeauth inside ugids_verify_make_auth, right? Without
being root, login makes ids of new user.
Isn't it right that password_check_{user,group}, used as default
verify_fn function in ugids_v
> Roland McGrath wrote:
> > There probably should be a runtime check in login that would catch this.
> > For example, checking for errors from proc_setowner would be good.
> > It also shouldn't manage to make the auth handles it asks for, and should
> > be complaining about that.
>
> I don't under
Roland McGrath wrote:
There probably should be a runtime check in login that would catch this.
For example, checking for errors from proc_setowner would be good.
It also shouldn't manage to make the auth handles it asks for, and should
be complaining about that.
I don't understand the last sentence
> I've finally found what's going on: login always expects to be run as
> root, and Debian's hurd package doesn't make it set-UID root. I've
> retitled 251863 and raised severity to important, hoping that next hurd
> package will include fix.
There probably should be a runtime check in login t
/* Cc: Jeff */
Roland McGrath wrote:
Both 251863 and the failure to set owner could be the same problem. They
would both happen if the login process were not properly authenticated as
root (to the proc server for setowner and to the tty filesystem for chown).
I've finally found what's going on: lo
On Thu, Aug 26, 2004 at 07:51:53AM +0300, [EMAIL PROTECTED] wrote:
> Even without debugging it's obvious that main process doesn't get owner
> (looking with ps, etc). I tried to investigate why, but I didn't succeed.
> As I said, this happens only when login is run as non-root or from
> inetutils
> Even without debugging it's obvious that main process doesn't get owner
> (looking with ps, etc). I tried to investigate why, but I didn't succeed.
login doesn't check for errors from its proc_setowner call.
Do you look at whether it said it worked?
___
Both 251863 and the failure to set owner could be the same problem. They
would both happen if the login process were not properly authenticated as
root (to the proc server for setowner and to the tty filesystem for chown).
___
Bug-hurd mailing list
[EM
> login forks the watchdog process and what it does is wake up and check if
> the main login process has an owner. If you've logged in, it should have
> one. What you should do is attach gdb to the watchdog process, and set a
> breakpoint in check_login. Then watch it talk to the proc server an
login forks the watchdog process and what it does is wake up and check if
the main login process has an owner. If you've logged in, it should have
one. What you should do is attach gdb to the watchdog process, and set a
breakpoint in check_login. Then watch it talk to the proc server and see
wha
Hi,
When login is run as ordinary user, and, more importantly, from
inetutils-telnetd, the following process appears (this is the ps name):
(watchdog for login 2107: 5 minutes remaining)
When time expires, the session is killed, login:ed or not. telnetd runs
login as root, but this doesn't prev
15 matches
Mail list logo
