> Well, I think that the exec server should remove EXECSERVERS, on the
> ground that it's the exec server that knows about the feature too.
That's what I was saying in the first place.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mai
Roland McGrath <[EMAIL PROTECTED]> wrote:
>> Anyhow, the point is a good one with respect to environment variables,
>> and perhaps we should enable EXECSERVERS with the suggested tweak,
>> that it is off for secure exec and for euid!=ruid.
>
> EXECSERVERS has to be excised from the environment, not
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Why is that? If it's programs that call setuid(getuid()) that have
> > this responsibility (as the original poster suggested), then this is
> > just fine. On the other hand, my vote is that it's the setuid program
> > itself that always has the resp
> Why is that? If it's programs that call setuid(getuid()) that have
> this responsibility (as the original poster suggested), then this is
> just fine. On the other hand, my vote is that it's the setuid program
> itself that always has the responsibility.
That is a new responsibility that ind
Roland McGrath <[EMAIL PROTECTED]> writes:
> > I thought there was some special Linux widget in the dynamic loader
> > that we don't support. Maybe that's just long gone.
>
> You are thinking of ld.so.cache.
Yes, that's right.
> > Anyhow, the point is a good one with respect to environment var
> I thought there was some special Linux widget in the dynamic loader
> that we don't support. Maybe that's just long gone.
You are thinking of ld.so.cache.
> Anyhow, the point is a good one with respect to environment variables,
> and perhaps we should enable EXECSERVERS with the suggested twea
Roland McGrath <[EMAIL PROTECTED]> writes:
> > > In Unix, if I run setuid program foo, and foo runs program bar, then
> > > the dynamic loader, noticing that ruid!=euid, will ignore LD_PRELOAD,
> > > etc., when loading bar. (Right?) This is because LD_PRELOAD is under
> > > the control of a user
> > In Unix, if I run setuid program foo, and foo runs program bar, then
> > the dynamic loader, noticing that ruid!=euid, will ignore LD_PRELOAD,
> > etc., when loading bar. (Right?) This is because LD_PRELOAD is under
> > the control of a user different from the one whose privileges we have
> >
[EMAIL PROTECTED] (Paul Jarc) writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote:
> > We don't want to change other execs, because there is no reason to
> > think there is any kind of security implication for them.
>
> Why not? Doesn't ruid!=euid have the same implications as in Unix?
> (I
[EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote:
> We don't want to change other execs, because there is no reason to
> think there is any kind of security implication for them.
Why not? Doesn't ruid!=euid have the same implications as in Unix?
(I.e., that a setuid program was executed, and no cod
[EMAIL PROTECTED] (Paul Jarc) writes:
> I agree - the kernel does not set uid=euid. (It preserves the old
> uid, and sets the new euid according to the file's owner.) I was
> saying something different: if there is a program running in a setuid
> situation (i.e., its real uid is different from i
[EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote:
> [EMAIL PROTECTED] (Paul Jarc) writes:
>> I don't know this Hurd stuff very well (or at all, nearly), but in
>> Unix terms, I'd say whatever code sets uid=euid (if any) in a setuid
>> situation should take responsibility for clearing dangerous
>> env
[EMAIL PROTECTED] (Paul Jarc) writes:
> I don't know this Hurd stuff very well (or at all, nearly), but in
> Unix terms, I'd say whatever code sets uid=euid (if any) in a setuid
> situation should take responsibility for clearing dangerous
> environment variables (or any other attributes of the pr
[EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote:
> Well, a setuid exec itself should disable EXECSERVERS. But the
> environment variable might still get inherited, and seven layers of
> fork/exec later, do something nasty. So that means that setuid exec
> should in fact clear EXECSERVERS in the pa
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>> What was the reason for disabling EXECSERVERS in exec? I think that
>> it is quite an useful feature when debugging exec, or playing around
>> with new features for it.
>
>This[1] thread might interest you.
>
>[1] http://mail
> What was the reason for disabling EXECSERVERS in exec? I think that
> it is quite an useful feature when debugging exec, or playing around
> with new features for it.
This[1] thread might interest you.
[1] http://mail.gnu.org/pipermail/bug-hurd/2000-May/001211.html
_
> What was the reason for disabling EXECSERVERS in exec? I think that
> it is quite an useful feature when debugging exec, or playing around
> with new features for it.
This[1] thread might interest you.
[1] http://mail.gnu.org/pipermail/bug-hurd/2000-May/001211.html
Interesting.
> I think there were just bugs and rather than figure them out, we
> commented it out. I think it would certainly be useful to turn it on
> and make it work.
There may have been bugs. There were also security concerns about
an EXECSERVERS being inherited indirectly by setuid programs and the li
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> What was the reason for disabling EXECSERVERS in exec? I think that
> it is quite an useful feature when debugging exec, or playing around
> with new features for it.
I think there were just bugs and rather than figure them out, we
commented it ou
What was the reason for disabling EXECSERVERS in exec? I think that
it is quite an useful feature when debugging exec, or playing around
with new features for it.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
20 matches
Mail list logo
