Hello
As most of you know, my Name is
Scott Li and I wrote most of you last week. I
told you about my
friend unemployment situation. For those who didnt get this or forgotten
what I
wrote. Then just scroll down to the bottom for a reca
> 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
> >
Moritz Schulte <[EMAIL PROTECTED]> writes:
> After I did the O_NOTRANS lookup in unionfs, I check if the resulting
> node is the same as the one returned by netfs_startup. If it is, I
> return ELOOP to make it impossible to reach the unionfs inside of the
> unionfs again, which would lead to infi
[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
Hello!
I have a couple of small suggestions regarding the build of GNUmach2
(oskit-mach). These are just simple stuff that I've found a bit annoying.
My make-fu is too weak [1] for me to present a patch though.
1. Change the OSKit version dependency in configure.in to,
at leas
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> What we really want is for the user to do a retry of the name as it
> exists in the "real" location, and then if that results in ENOENT,
> we want the user to return back to the filesystem for another name
> to try.
Well, here you are only consid
Remember to compile the Hurd with debugging symbols, else the back-trace
will be useless.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
You can get some helpful information out of ftpfs like this:
Start an active ftpfs instance:
$ settrans -afg node /hurd/ftpfs --HANG=
Now you have seconds left to attach gdb to the ftpfs process
on a different terminal: get the PID via ps and then:
$ gdb /hurd/ftpfs
Let the process continue
[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
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Actually I was not thinking about making ".." go to the unionfs, but
> this surely seems like a good idea.
>
> > If it's a translator (of any kind, including symlink) then it does
> > the translator linkage *itself*, just as diskfs/netfs does it.
>
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Oh, that. Blech blech blech.
Blech is also corking.
> And, of course, this matters in just this case! Because it's a
> union, and so the node is found in *two* directories and it's not at
> all clear which one is right.
I'm not sure wether I
19 matches
Mail list logo
