On Thu, Dec 19, 2002 at 02:54:16PM -0500, David Walter wrote:
> Joachim Nilsson <[EMAIL PROTECTED]> writes:
> > I've noticed that too. Have you tried out Daniel Wagners patch[1] to
> > disable soft interrupt handling in the spl code?
> > [1] - http://mail.gnu.org/pipermail/bug-hurd/2002-December/01
[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
On 19 Dec 2002, Thomas Bushnell, BSG wrote:
> "Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>
> >> Corking.
> >
> >What's that mean?
> >
> > >From WordNet (r) 1.7 [wn]:
> >
> > corking
> >adj : (informal) very good; "a bully pulpit"; "a neat sports car";
> > "had a
[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
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > What exactly would the problem be there? Maybe I've missed a beat
> > in the conversation.
>
> Maybe I am overlooking something, I am not that familiar with
> libdiskfs.
>
> My question is: give
[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
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> What exactly would the problem be there? Maybe I've missed a beat
> in the conversation.
Maybe I am overlooking something, I am not that familiar with
libdiskfs.
My question is: given the situation that dir_lookup is called to
re-open a node, w
> 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
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > I think the right fix is to have lookups for "" do all the normal
> > processing when you open a file.
>
> Well, yes, but the problem of relative symbolic links is not yet
> solved, is it?
What e
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
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I think the right fix is to have lookups for "" do all the normal
> processing when you open a file.
Well, yes, but the problem of relative symbolic links is not yet
solved, is it?
moritz
--
[EMAIL PROTECTED] - http://duesseldor
Moritz Schulte <[EMAIL PROTECTED]> writes:
> > It might well be that we have a hole in the interface here. Blech.
>
> So... fs interface change - anyone? =)
I think the right fix is to have lookups for "" do all the normal
processing when you open a file.
That is, it should do the translator s
> corking
>adj : (informal) very good; "a bully pulpit"; "a neat sports car";
> "had a great time at the party"; "you look simply
> smashing" [syn: {bang-up}, {bully}, {cracking}, {dandy},
> {great}, {groovy}, {keen}, {neat}, {nifty},
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>> Corking.
>
>What's that mean?
>
> >From WordNet (r) 1.7 [wn]:
>
> corking
>adj : (informal) very good; "a bully pulpit"; "a neat sports car";
> "had a great time at the party"; "you look simply
> smash
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I think that's why I originally stated "." which Roland corrected to
> "".
Well, "." would not work for non-directories, of course.
> It might well be that we have a hole in the interface here. Blech.
So... fs interface change - anyone? =)
> Corking.
What's that mean?
>From WordNet (r) 1.7 [wn]:
corking
adj : (informal) very good; "a bully pulpit"; "a neat sports car";
"had a great time at the party"; "you look simply
smashing" [syn: {bang-up}, {bully}, {cracking}, {dandy},
{g
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>> Still, is the unused code somehow filtered out from the source tree
>> when a release is made?
>
>See hurd/Makefile.
>
> Corking.
What's that mean?
___
Bug-hurd mailing list
[EMAIL PROTEC
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Instead, you fetch the actual node, and then tell the user to reauth
> *that* node.
Are you sure the needed functionality is implemented?
I tried that, it does not work (with a retry name of ""); the user
keeps the underlying node, he doesn't ge
> Still, is the unused code somehow filtered out from the source tree
> when a release is made?
See hurd/Makefile.
Corking.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>> The problem with having them still in the tree is that it's not obvious
>> at a quick glance which tools are pieces aer still in use and worth
>> learning when you're a new person. As an example, when James Morrison
>> was doing pa
On Thu, Dec 19, 2002 at 09:08:59PM +0100, Alfred M. Szmidt wrote:
> Still, is the unused code somehow filtered out from the source tree
> when a release is made?
With automake yes. 'make dist' only pulls in the files that are
actively referenced in the make files. That is, incidentally, what I'
> The problem with having them still in the tree is that it's not obvious
> at a quick glance which tools are pieces aer still in use and worth
> learning when you're a new person. As an example, when James Morrison
> was doing patch reviews and sending a patch nearly every week a freq
Joachim Nilsson <[EMAIL PROTECTED]> writes:
> I've noticed that too. Have you tried out Daniel Wagners patch[1] to
> disable soft interrupt handling in the spl code?
>
>
> Regards
> /Joachim
>
> [1] - http://mail.gnu.org/pipermail/bug-hurd/2002-December/011134.html
That link appears to be empty
Jeff Bailey <[EMAIL PROTECTED]> writes:
> The problem with having them still in the tree is that it's not obvious
> at a quick glance which tools are pieces aer still in use and worth
> learning when you're a new person. As an example, when James Morrison
> was doing patch reviews and sending a p
Hi
I am running a cvs hurd and it seems that ftpfs is broken. Actually I don't know if
it's ftpfs, could be something. What happens
is I try "settrans -a /gnu /hurd/ftpfs / ftp.debian.org" and I get translator died
emediately. When I try without the -a option I get no translator death until I cd
29 matches
Mail list logo
