|
|
|
|
|
|
| Author |
Message |
Christian Perrier
*nix forums Guru Wannabe
Joined: 22 Mar 2005
Posts: 204
|
 Posted: Thu Jul 06, 2006 5:34 am Post subject:
Re: Bug#374525: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
Colin Percival:
| Quote: | FWIW, nologin was in /sbin in BSD 4.4; this is almost certainly why
OpenBSD still has /sbin/nologin.
I moved FreeBSD's nologin to /usr/sbin two years ago, because
|
Thanks a lot for taking time to detail all this. This is very helpful
to make a decision. I like such interesting collaboration.
The balance is currently more and more in favor of /usr/sbin for
Debian...which is nice because this is what we use right now..:-)
Reformulation: Jari, you need to bring strong arguments if you want us
to change this, now.. . This is not a "go away" answer but I think
that maintaining your request for moving nologin to /bin will need you
to give work to our Technical Committee.. |
|
| Back to top |
|
 |
Jari Aalto
*nix forums beginner
Joined: 08 Feb 2005
Posts: 47
|
| Posted: Thu Jul 06, 2006 3:04 pm Post subject:
Re: Bug#374525: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
| Colin Percival:
|
| > FWIW, nologin was in /sbin in BSD 4.4; this is almost certainly why
| > OpenBSD still has /sbin/nologin.
| >=20
| > I moved FreeBSD's nologin to /usr/sbin two years ago, because
|
|
| Thanks a lot for taking time to detail all this. This is very helpful
| to make a decision. I like such interesting collaboration.
|
| The balance is currently more and more in favor of /usr/sbin for
| Debian...which is nice because this is what we use right now..
|
| Reformulation: Jari, you need to bring strong arguments if you want us
| to change this, now... This is not a "go away" answer but I think
| that maintaining your request for moving nologin to /bin will need you
| to give work to our Technical Committee..:-)
Please go ahead, I have no objections. Glad to see this issue resolved.
Jari
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Colin Percival
*nix forums addict
Joined: 10 Dec 2004
Posts: 61
|
| Posted: Fri Jul 07, 2006 5:14 am Post subject:
Bug#374525: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
Tomasz K?oczko wrote:
| Quote: | On Wed, 5 Jul 2006, Colin Percival wrote:
I moved FreeBSD's nologin to /usr/sbin two years ago, because
1. nologin needs to be statically linked to avoid linker environment
security issues,
Key word in this case is "avoiding". If some bad things sits in ld.so why
not fix this directly ?
Also strange thing IMO is in this case is nologin static linking. Yes I
know about ssh pass LD_* but IMO fixing this by static linking is
incorrect way because this is only next "avoiding" ..
|
FreeBSD's dynamic linker knows about the security issues involving LD_*
(set[ug]id binaries and noexec filesystems) and acts accordingly. However,
/usr/sbin/nologin is not set[ug]id, and unlike other shells, we care if a
user can subvert it by preloading libraries.
Debian might have a different solution to this problem; but this one works
for FreeBSD.
Colin Percival
--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian..org |
|
| Back to top |
|
|
Christian Perrier
*nix forums Guru Wannabe
Joined: 22 Mar 2005
Posts: 204
|
| Posted: Fri Jul 07, 2006 5:36 am Post subject:
Re: Bug#366546: Bug#374525: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
(shortening the CC list a little, assuming that ppl from the FreeBSD
project read freebsd-arch which seems likely)
| Quote: | FreeBSD's dynamic linker knows about the security issues involving LD_*
(set[ug]id binaries and noexec filesystems) and acts accordingly. However,
/usr/sbin/nologin is not set[ug]id, and unlike other shells, we care if a
user can subvert it by preloading libraries.
Debian might have a different solution to this problem; but this one works
for FreeBSD.
Colin Percival
|
To refix the context, Tomasz Klockzko, who you're answering to, is not
working in the Debian project, but is the upstream author of shadow,
which provides two binary packages in Debian, namely login and
passwd. nologin is provided in the "login" package.
So, in short, Tomasz does not really speak with a Debian-centric
reasoning but more with his upstream hat (upstream for "our" nologin
of course).
-- |
|
| Back to top |
|
|
Jari Aalto
*nix forums beginner
Joined: 08 Feb 2005
Posts: 47
|
| Posted: Fri Jul 07, 2006 3:14 pm Post subject:
Re: Bug#374525: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
| Colin Percival:
|
| > FWIW, nologin was in /sbin in BSD 4.4; this is almost certainly why
| > OpenBSD still has /sbin/nologin.
| >=20
| > I moved FreeBSD's nologin to /usr/sbin two years ago, because
|
|
| Thanks a lot for taking time to detail all this. This is very helpful
| to make a decision. I like such interesting collaboration.
|
| The balance is currently more and more in favor of /usr/sbin for
| Debian...which is nice because this is what we use right now..
|
| Reformulation: Jari, you need to bring strong arguments if you want us
| to change this, now... This is not a "go away" answer but I think
| that maintaining your request for moving nologin to /bin will need you
| to give work to our Technical Committee..:-)
Please go ahead, I have no objections. Glad to see this issue resolved.
Jari
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Jari Aalto
*nix forums beginner
Joined: 08 Feb 2005
Posts: 47
|
| Posted: Fri Jul 07, 2006 3:22 pm Post subject:
Re: Bug#374525: [Pkg-shadow-devel] Bug#374525: Bug#366546: Mail delivery failed: returning message to sender
|
|
|
| Colin Percival:
|
| > FWIW, nologin was in /sbin in BSD 4.4; this is almost certainly why
| > OpenBSD still has /sbin/nologin.
| >=20
| > I moved FreeBSD's nologin to /usr/sbin two years ago, because
|
|
| Thanks a lot for taking time to detail all this. This is very helpful
| to make a decision. I like such interesting collaboration.
|
| The balance is currently more and more in favor of /usr/sbin for
| Debian...which is nice because this is what we use right now..
|
| Reformulation: Jari, you need to bring strong arguments if you want us
| to change this, now... This is not a "go away" answer but I think
| that maintaining your request for moving nologin to /bin will need you
| to give work to our Technical Committee..:-)
Please go ahead, I have no objections. Glad to see this issue resolved.
Jari
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Mon Jul 31, 2006 5:08 pm Post subject:
RE: Changes in the network interface queueing handoff model
|
|
|
On Mon, 31 Jul 2006, John Polstra wrote:
| Quote: | Attached is a patch that maintains the current if_start, but adds
if_startmbuf. If a device driver implements if_startmbuf and the global
sysctl net.startmbuf_enabled is set to 1, then the if_startmbuf path in the
driver will be used. Otherwise, if_start is used. I have modified the
if_em driver to implement if_startmbuf also. If there is no packet backlog
in the if_snd queue, it directly places the packet in the transmit
descriptor ring. If there is a backlog, it uses the if_snd queue protected
by driver mutex, rather than a separate ifq mutex.
I question whether you need a fallback software if_snd queue at all for
modern devices such as the Intel and Broadcom gigabit chips. The hardware
transmit descriptor rings typically have sizes of the order of 256
descriptors. I think if the ring fills up, you could simply drop the packet
with ENOBUFS. That's what happens if the if_snd queue fills up, and its
maximum size is comparable to the sizes of modern descriptor rings. It
would simplify things quite a bit to eliminate the if_snd queue entirely for
such devices.
|
I tend to agree, but implemented full queueing support for if_em to make sure
I understood to complexity implications of completely removing queueing from
the ifnet side dispatch. I guess an interesting question for us is how we
decide what the right threshold is to implement software queuing. Do any
if_em cards need software queueing, or do they all have adequate in-hardware
queues as is? Entirely cutting the queue code would significantly simplify
em_startmbuf.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Petri Helenius
*nix forums beginner
Joined: 31 Jul 2006
Posts: 1
|
| Posted: Mon Jul 31, 2006 5:21 pm Post subject:
Re: Changes in the network interface queueing handoff model
|
|
|
Robert Watson wrote:
| Quote: |
I tend to agree, but implemented full queueing support for if_em to
make sure I understood to complexity implications of completely
removing queueing from the ifnet side dispatch. I guess an
interesting question for us is how we decide what the right threshold
is to implement software queuing. Do any if_em cards need software
queueing, or do they all have adequate in-hardware queues as is?
Entirely cutting the queue code would significantly simplify
em_startmbuf.
Actually most em cards support 4096 descriptors each way. |
Pete
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
John Polstra
*nix forums beginner
Joined: 23 Aug 2002
Posts: 14
|
| Posted: Mon Jul 31, 2006 5:34 pm Post subject:
Re: Changes in the network interface queueing handoff model
|
|
|
On 31-Jul-2006 Petri Helenius wrote:
| Quote: | Robert Watson wrote:
I tend to agree, but implemented full queueing support for if_em to
make sure I understood to complexity implications of completely
removing queueing from the ifnet side dispatch. I guess an
interesting question for us is how we decide what the right threshold
is to implement software queuing. Do any if_em cards need software
queueing, or do they all have adequate in-hardware queues as is?
Entirely cutting the queue code would significantly simplify
em_startmbuf.
Actually most em cards support 4096 descriptors each way.
|
Yes, even the earliest ones supported 4096 descriptors on paper. In
practice, the early chips had bugs that required the entire descriptor
ring to fit in a single page of memory. That limited them to 4096/16
= 256 transmit descriptors on x86 hardware at the time. That chip
bug was fixed a long time ago, though, and in any case 256 transmit
descriptors is a lot for most applications.
John
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
John-Mark Gurney
*nix forums addict
Joined: 16 Jun 2003
Posts: 89
|
| Posted: Mon Jul 31, 2006 7:09 pm Post subject:
Re: Changes in the network interface queueing handoff model
|
|
|
Robert Watson wrote this message on Mon, Jul 31, 2006 at 18:08 +0100:
| Quote: | I question whether you need a fallback software if_snd queue at all for
modern devices such as the Intel and Broadcom gigabit chips. The hardware
transmit descriptor rings typically have sizes of the order of 256
descriptors. I think if the ring fills up, you could simply drop the
packet with ENOBUFS. That's what happens if the if_snd queue fills up,
and its maximum size is comparable to the sizes of modern descriptor
rings. It would simplify things quite a bit to eliminate the if_snd queue
entirely for such devices.
I tend to agree, but implemented full queueing support for if_em to make
sure I understood to complexity implications of completely removing
queueing from the ifnet side dispatch. I guess an interesting question for
us is how we decide what the right threshold is to implement software
queuing. Do any if_em cards need software queueing, or do they all have
adequate in-hardware queues as is? Entirely cutting the queue code would
significantly simplify em_startmbuf.
|
This work tends to lead to a generic ethernet card framework that I've
been thinking about.. where instead of cards doing all the handling of
a ring buffer, the card registers a few functions to manipulate a ring
buffer (if it has one), and does the necessary work... Though encoding
all the different style of ring buffers may be interesting, per packet
instead of per segment (if_re)...
The other part is to digest the current monolithic lock structure that
the ethernet cards have, into three (or four) different locks, tx head,
tx tail, rx head & tail...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Bruce Evans
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 190
|
| Posted: Wed Aug 02, 2006 10:01 am Post subject:
RE: Changes in the network interface queueing handoff model
|
|
|
On Mon, 31 Jul 2006, John Polstra wrote:
| Quote: | I question whether you need a fallback software if_snd queue at all
for modern devices such as the Intel and Broadcom gigabit chips. The
hardware transmit descriptor rings typically have sizes of the order
of 256 descriptors. I think if the ring fills up, you could simply
drop the packet with ENOBUFS. That's what happens if the if_snd queue
fills up, and its maximum size is comparable to the sizes of modern
descriptor rings. It would simplify things quite a bit to eliminate
the if_snd queue entirely for such devices.
|
I use an if_snd queue length of about 5000 in my version of the sk
driver to work around suckage in ENOBUFS handling. The hardware (*)
tx ring size is 512, and tiny packets can be sent in 4 usec, so the
hardware queue provides only 2 msec worth of buffering. select(2)
for output on sockets doesn't work right, so there is no good way (**)
for applications to proceed when a syscall returns ENOBUFS. An extra
queue length of 500 provides an extra 20 msec worth of buffering which
is usually enough when HZ = 100.
(*) I think the sk tx ring is not really in hardware, so it can be
much larger than 512, but a length of > 5000 for it seems excessive
and caused panics when I tried it.
(**) Various bad ways can be found in various versions of ttcp and
tools/netrate. They involve either backing off by sleeping (which
doesn't keep the tx active unless the sleep granularity is small
(which only happens under FreeBSD if HZ is too large)), or by never
backing off (which gives busy-waiting). Instead, select() on the
output socket should actually work -- it should succeed if the tx
queue length is below a low watermark. Apparently, select() on
output sockets normally doesn't work, since no version of ttcp that
I've looked at (not many) even tries this.
Bruce
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Nov 22, 2008 8:17 pm | All times are GMT
|
|
Payday Loan | Debt Consolidation | Free phpBB forum | Loans | Loans
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
