Ponga su anuncio de forma gratuita

[Inmobiliam News]

  
  

  


   

  
Tuanunciogratis

   

  

  








___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

autoconf update patches

[Alfred M. Szmidt]

Can we _please_ apply the patches for updating all the related
autoconf code right now?

The worst case scenario that will happen is that we won't be able to
bootstrap, and if that actually would happen then we have two choices,
revert or fix; both which are trivial.


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[patch #1809] Fix small typo in ext2_fs.h

[Alfred M. Szmidt]

Update of patch #1809 (project hurd):

Priority:  5 - Normal => 1 - Later  


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

IMPORTANT: your message to png-group

[W3C List Manager]

This is a response to a message apparently sent from your address to
[EMAIL PROTECTED]:

Subject: Transparenz ist das Mindeste
From:bug-hurd@gnu.org
Date:Wed, 18 May 2005 02:06:39 GMT

Your message has NOT been distributed to the list; before we distribute it,
we need your permission to include your message in our Web archive of all
messages distributed to this list.

Please visit:

http://www.w3.org/Mail/review?id=b13288b6cd8fceb93785

and follow the simple procedure listed to give us permission to include
your message in our Web archives. It should take less than one minute
of your time, and only needs to be done once.

If you do not give us this permission by Wed May 25 02:07:59 UTC 2005,
your message will be deleted from our systems without being distributed
to the list.

Please do not reply to this message; for more information on this system,
including information on how to provide feedback, please see:

http://www.w3.org/2002/09/aa/

Note: W3C's mailing lists may not be used for unsolicited bulk email
of any kind!

-- 
W3C Postmaster, http://www.w3.org/Mail/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

IMPORTANT: your message to html-tidy

[W3C List Manager]

This is a response to a message apparently sent from your address to
[EMAIL PROTECTED]:

Subject: Transparenz ist das Mindeste
From:bug-hurd@gnu.org
Date:Wed, 18 May 2005 02:06:39 GMT

Your message has NOT been distributed to the list; before we distribute it,
we need your permission to include your message in our Web archive of all
messages distributed to this list.

Please visit:

http://www.w3.org/Mail/review?id=0788412120d451ffd93d

and follow the simple procedure listed to give us permission to include
your message in our Web archives. It should take less than one minute
of your time, and only needs to be done once.

If you do not give us this permission by Wed May 25 02:07:59 UTC 2005,
your message will be deleted from our systems without being distributed
to the list.

Please do not reply to this message; for more information on this system,
including information on how to provide feedback, please see:

http://www.w3.org/2002/09/aa/

Note: W3C's mailing lists may not be used for unsolicited bulk email
of any kind!

-- 
W3C Postmaster, http://www.w3.org/Mail/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: non-blocking connect fails with no pending acceptors

[Thomas Bushnell BSG]

"Neal H. Walfield" <[EMAIL PROTECTED]> writes:

> If a program calls connect on a non-blocking socket with no pending
> acceptors (i.e. threads calling accept on the listening end of a
> socket), connect fails with EWOULDBLOCK.  It is unclear to me if this
> behavior is POSIX-conforming or not [1], however, (1) there are programs
> which do not expect this behavior; and (2) connect on other systems
> does not block before the number of connects without a accept exceeds
> the listen queue length (we treat the queue length as the maximum
> number of threads which can block doing a connect).

You think the behavior should be to allow the connect to succeed
immediately?  Ok, that's fine, but what then happens when you try to
move data... should it block, waiting for the connection to actually
be made?

Thomas


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

3.25 rate confirmation #835496JA Wed, 18 May 2005 09:49:23 -0800

[[EMAIL PROTECTED]]

Hello,

We sent you an email a while ago, because you now qualify
for a much lower rate based on the biggest rate drop in years.

You can now get $327,000 for as little as $617 a month!
Bad credit? Doesn't matter, ^low rates are fixed no matter what!

Follow this link to process your application and a 24 hour approval:

http://www.1ncr3dible.com/74.asp

Best Regards,
Terrance Landry


http://www.1ncr3dible.com/gone.asp


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: breaking out of a chroot

[Alfred M. Szmidt]

   Breaking out of a chroot on the Hurd is trivial: just use a passive
   translator.

I couldn't reproduce this...

Script started on Wed May 18 06:19:32 2005
[EMAIL PROTECTED]:~$ cd chroot
[EMAIL PROTECTED]:~/chroot$ ids
effective uids: 1002(ams)
effective gids: 1002(ams)
available uids: 1002(ams) 1002(ams)
available gids: 1002(ams) 1002(ams) 1002(ams)
[EMAIL PROTECTED]:~/chroot$ chroot .
bash-3.00$ showtrans root
bash-3.00$ settrans -p root /hurd/firmlink /
bash-3.00$ showtrans root
/hurd/firmlink /
bash-3.00$ cd /
bash-3.00$ ls
bin  hurd  lib  root
bash-3.00$ exit
exit
[EMAIL PROTECTED]:~/chroot$ exit
exit

Script done on Wed May 18 06:20:58 2005


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: buglet in pflocal/sock.c

[Roland McGrath]

Looks right.


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: non-blocking connect fails with no pending acceptors

[Roland McGrath]

> If a program calls connect on a non-blocking socket with no pending
> acceptors (i.e. threads calling accept on the listening end of a
> socket), connect fails with EWOULDBLOCK.

This is doubly wrong.  When listen has been called and the queue limit not
reached, then the connection should be established immediately and not wait
for someone to call accept.  When the connection cannot be established
immediately and the socket is nonblocking, connect should return
EINPROGRESS.  This should happen when the queue limit has been reached.
(And then the client socket should be in "waiting to connect" state and a
later connect call should return EALREADY.)

I haven't read through your patch yet, but these are the semantics that
pflocal should be implementing.  For a real network stack it's the same.
The listen queue limit being reached on the remote end corresponds to the
client getting an ACK as if its packet hadn't gone through.


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: breaking out of a chroot

[Thomas Bushnell BSG]

"Neal H. Walfield" <[EMAIL PROTECTED]> writes:

> Breaking out of a chroot on the Hurd is trivial: just use a passive
> translator.  A passive translator will inherit the namespace of the
> file system which started it, not the process which set it.  Thus, a
> chroot'ed user need only run:
>
>   settrans -c root /hurd/firmlink /
>
> Neighbor Hurds won't suffer from this problem.
>
> I don't have any ideas offhand of how this could be fixed.

It's easier than that; you can just directly ask the proc server for
the global system root.

The Hurd doesn't have Unixy chroots by design, but you can make a
subhurd which you can't break out of.  That's the correct way to solve
the problems that Unix solves with chroot.

Thomas



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[EMAIL PROTECTED](BDevotion$B!j(B

[info]

$B'$'T'$'T'$'T'$'T'$'T'$'T'$'T'$'T'$'T'$'T'$(B

$B'T!!'T(B

$B'$F|K\:GBg5iEPO?!JL5NA!K%(%s%H%j!http://www.lovegal2.net?free1000  $B'T(B

$B'$",@lMQF~8}",!!'$(B

$B'T!!(B  $B!!4|4VCf$K-dEPO?D:$/$H'T(B

$B'$(B10,000$B1_J,$N(B1000Pt$B%5!<%S%9Cf!*'$(B

$B'T!!'T(B

$B'$'T'$'T'$'T'$'T'$'T'$'T'$'T'$'T'$'T'$'T'$(B







$B!!!y!!4JC1!uL5NAEPO?!!C/$G$bA`:[EMAIL PROTECTED]@_7W!y(B

$B!!!y!!http://www.lovegal2.net?free1000

$B!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W(B



$B!!!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z(B



$B1?1D%9%?%C%U$,[EMAIL PROTECTED]@[EMAIL PROTECTED](B

[EMAIL PROTECTED];[EMAIL PROTECTED];H$$$d$9$5!"%G%6%$%s$K$J$C$F$*$j$^$9!#(B

[EMAIL PROTECTED](B,$BGME]H/[EMAIL PROTECTED],$"$jo;~GS=|(B

[EMAIL PROTECTED](B

$B!V!!BN$OBg?M!*?4$O;R6!!*!!!W!!(B

$B$N$h$&$J5U%3%J%s7/7O$NJ}$O$7$C$+$j%^%J!<$rhttp://www.lovegal2.net?free1000

$B!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W!W(B



$B!!!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z(B











$B(B $B!!Ev%a!<%k$NL5CGE>:\(B,$B5-:[EMAIL PROTECTED](B


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: non-blocking connect fails with no pending acceptors

[Neal H. Walfield]

At Tue, 17 May 2005 22:03:13 -0700 (PDT),
Roland McGrath wrote:
> 
> > If a program calls connect on a non-blocking socket with no pending
> > acceptors (i.e. threads calling accept on the listening end of a
> > socket), connect fails with EWOULDBLOCK.
> 
> This is doubly wrong.  When listen has been called and the queue limit not
> reached, then the connection should be established immediately and not wait
> for someone to call accept.

My patch changes pflocal to exhibit this behavior.

>  When the connection cannot be established
> immediately and the socket is nonblocking, connect should return
> EINPROGRESS.  This should happen when the queue limit has been reached.
> (And then the client socket should be in "waiting to connect" state and a
> later connect call should return EALREADY.)

POSIX also says "[t]he implementation may include incomplete
connections in its listen queue. The limits on the number of
incomplete connections and completed connections queued may be
different."  I understand "incomplete connections" as meaning
connection requests which are established asynchronously.  Do you
agree with this interpretation?

Assuming my understanding is correct, if an implementation includes
"incomplete connections" in the listen queue, the only time
connections would be established asynchronously is when the listen
queue is full in which case the implementation would have to return an
error to the user (POSIX doesn't seem to specify what error to return
here).  Alternatively, an implementation could set the queue length of
incomplete connections to zero with the same results.  The patch that
I sent assumes one of these interpretations and returns EWOULDBLOCK
when the queue is full.

I've tested the aforementioned socket program on 3 systems.  On Linux
(2.6.9), it returns EWOULDBLOCK after 11 successful connects.  On
Tru64, socket() fails with EMFILE (too many open files) when creating
the 4094th socket.  On FreeBSD 4.10, the program successfully connects
17 sockets before failing with ECONNREFUSED.  It seems that none of
these systems implement a separate incomplete connection queue.

I don't see any technical advantage in adding an incomplete connection
queue to our implementation.  Internally, it is not useful (i.e. the
Hurd proper does not require it).  Since no one else seems to
implement this behavior, programs don't rely on it.  Moreover,
programs may incorrectly detect EINPROGRESS as a fatal error and
abort.  I'm not suggesting that we support incorrect programs, but I
don't think we should go out of our way to support functionality which
is not even terribly useful.

Do you agree?

Thanks,
Neal


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: non-blocking connect fails with no pending acceptors

[Neal H. Walfield]

At Tue, 17 May 2005 19:05:52 -0700,
Thomas Bushnell BSG wrote:
> 
> "Neal H. Walfield" <[EMAIL PROTECTED]> writes:
> 
> > If a program calls connect on a non-blocking socket with no pending
> > acceptors (i.e. threads calling accept on the listening end of a
> > socket), connect fails with EWOULDBLOCK.  It is unclear to me if this
> > behavior is POSIX-conforming or not [1], however, (1) there are programs
> > which do not expect this behavior; and (2) connect on other systems
> > does not block before the number of connects without a accept exceeds
> > the listen queue length (we treat the queue length as the maximum
> > number of threads which can block doing a connect).
> 
> You think the behavior should be to allow the connect to succeed
> immediately?

I guess that is one way to interpret it.  The socket interface is not
a topic that I am very interested: it seems adequate; my end was only
to make the Hurd more POSIX compliant and what I proposed is an
attempt to do this.  If you want to support some non-POSIX behavior as
an extension, I don't see any reason we couldn't do that.  I think
that we shouldn't do that, however, unless the interfaces actually
solve a specific problem which we are able to articulate.  I don't see
the current interface as having any technical advantages over what
POSIX requires.  In fact, it only creates problems: programs rely no
POSIX.  Since nothing relies on the old behavior, I see no reason to
retain it.

>  Ok, that's fine, but what then happens when you try to
> move data... should it block, waiting for the connection to actually
> be made?

I don't understand.  The connection is "actually" made when you call
connect.  POSIX says[1]:

  If the initiating socket is connection-mode, then connect() shall
  attempt to establish a connection to the address specified by the
  address argument. If the connection cannot be established
  immediately and O_NONBLOCK is not set for the file descriptor for
  the socket, connect() shall block

As I understand it, if connect succeeds, the connection has "actually"
been made.  This is what my patch does.

Thanks,
Neal

[1] http://www.opengroup.org/onlinepubs/009695399/functions/connect.html



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: buglet in pflocal/sock.c

[Neal H. Walfield]

At Tue, 17 May 2005 21:49:21 -0700 (PDT),
Roland McGrath wrote:
> Looks right.

I've checked this in.


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: breaking out of a chroot

[Neal H. Walfield]

At Wed, 18 May 2005 00:23:11 -0400,
Alfred M. Szmidt wrote:
> 
>Breaking out of a chroot on the Hurd is trivial: just use a passive
>translator.
> 
> I couldn't reproduce this...
> 
> Script started on Wed May 18 06:19:32 2005
> [EMAIL PROTECTED]:~$ cd chroot
> [EMAIL PROTECTED]:~/chroot$ ids
> effective uids: 1002(ams)
> effective gids: 1002(ams)
> available uids: 1002(ams) 1002(ams)
> available gids: 1002(ams) 1002(ams) 1002(ams)
> [EMAIL PROTECTED]:~/chroot$ chroot .
> bash-3.00$ showtrans root
> bash-3.00$ settrans -p root /hurd/firmlink /
> bash-3.00$ showtrans root
> /hurd/firmlink /
> bash-3.00$ cd /

This bit is wrong.  root now gives access to the real root (or at
least the root in the file system's name space).


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: breaking out of a chroot

[Neal H. Walfield]

> > I don't have any ideas offhand of how this could be fixed.
> 
> It's easier than that; you can just directly ask the proc server for
> the global system root.

One can proxy the proc server.

> The Hurd doesn't have Unixy chroots by design, but you can make a
> subhurd which you can't break out of.  That's the correct way to solve
> the problems that Unix solves with chroot.

I'm not suggesting that we should fix Unix's chroot with our chroot.
However, there are a fair number of programs (namely daemons) which
understand the security holes and are able, nevertheless, to take
advantages of Unix's chroot behavior.  The fact that our chroot is
less secure than Unix's deserves, I think, at least a caveat.

Thanks,
Neal


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: breaking out of a chroot

[Thomas Bushnell BSG]

"Neal H. Walfield" <[EMAIL PROTECTED]> writes:

> I'm not suggesting that we should fix Unix's chroot with our chroot.
> However, there are a fair number of programs (namely daemons) which
> understand the security holes and are able, nevertheless, to take
> advantages of Unix's chroot behavior.  The fact that our chroot is
> less secure than Unix's deserves, I think, at least a caveat.

Yes, that's a documentation bug.  :)  

It is possible that we should have a facility for those daemons to
use, but regardless we should make clear that the Hurd's chroot is not
a security feature.


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: non-blocking connect fails with no pending acceptors

[Thomas Bushnell BSG]

"Neal H. Walfield" <[EMAIL PROTECTED]> writes:

> I don't understand.  The connection is "actually" made when you call
> connect.  POSIX says[1]:
>
>   If the initiating socket is connection-mode, then connect() shall
>   attempt to establish a connection to the address specified by the
>   address argument. If the connection cannot be established
>   immediately and O_NONBLOCK is not set for the file descriptor for
>   the socket, connect() shall block
>
> As I understand it, if connect succeeds, the connection has "actually"
> been made.  This is what my patch does.

Right, without anyone listening on the other end.

In other words, normally the connection made means that both sides
have, um, completed the connection.  The change would allow the
"connect" side to say "yep, got a connection" even though there is no
listener.




___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: non-blocking connect fails with no pending acceptors

[Thomas Bushnell BSG]

Roland McGrath <[EMAIL PROTECTED]> writes:

>> If a program calls connect on a non-blocking socket with no pending
>> acceptors (i.e. threads calling accept on the listening end of a
>> socket), connect fails with EWOULDBLOCK.
>
> This is doubly wrong.  When listen has been called and the queue limit not
> reached, then the connection should be established immediately and not wait
> for someone to call accept.  When the connection cannot be established
> immediately and the socket is nonblocking, connect should return
> EINPROGRESS.  This should happen when the queue limit has been reached.
> (And then the client socket should be in "waiting to connect" state and a
> later connect call should return EALREADY.)

Right.  I misunderstood and thought not even listen had been called.

If listen has been called, then connections should complete, local
ones should complete instantly.



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

(no subject)

[dkcnlal]

___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: autoconf update patches

[Alfred M. Szmidt]

   What kind of bootstrapping are you talking about anyway?

Please see previous threads in the archive about this.

   If someone expects something won't work, we can test it.

And then expect that nobody actually does the test? Right


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: autoconf update patches

[Marco Gerards]

"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:

> Can we _please_ apply the patches for updating all the related
> autoconf code right now?
>
> The worst case scenario that will happen is that we won't be able to
> bootstrap, and if that actually would happen then we have two choices,
> revert or fix; both which are trivial.

What kind of bootstrapping are you talking about anyway?  IIRC
everything worked with these patches.  If someone expects something
won't work, we can test it.

--
Marco



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: non-blocking connect fails with no pending acceptors

[Roland McGrath]

> If listen has been called, then connections should complete, local
> ones should complete instantly.

Not when the queue limit has already been reached, right?


___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: autoconf update patches

[Marcus Brinkmann]

At Wed, 18 May 2005 02:02:26 +0200,
Alfred M Szmidt wrote:
> 
> Can we _please_ apply the patches for updating all the related
> autoconf code right now?

Cans omebody please do the bootstrap test?  What's the problem with
just testing the one potentially problematic scenario?

> The worst case scenario that will happen is that we won't be able to
> bootstrap, and if that actually would happen then we have two choices,
> revert or fix; both which are trivial.

So fix it now, before having the patches applied, if it doesn't work
already.

Thanks,
Marcus



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd