similar to: [Bug 1223] tun/tap capability only works with root login (openssh-4.3_p2)

http://bugzilla.mindrot.org/show_bug.cgi?id=1223 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|tun/tap capability only |tun/tap capability requires |works with root login |root privileges

The attached patch is against openssh-4.3_p2 to allow non-root users to vpn in over ssh. root access is still needed on client side (or an sudo solution). Currently, I have it working with an sudo command to configure a tap interface on the server side. eg to ssh into my gentoo server: # ssh -fw any:any user at ssh_server.box "sudo /etc/init.d/net.tap0 restart" Then, configure the

The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch

The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch

The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch

The problem with introducing checksum offload and gso to tun is they need to set dev->features to enable GSO and/or checksumming, which is supposed to be done before register_netdevice(), ie. as part of TUNSETIFF. Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand, so there's no good way of detecting whether the kernel supports new IFF_ flags. This patch

On Sat, Jul 05, 2014 at 11:04:53AM +0530, Amit Shah wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes the host to not

On Sat, Jul 05, 2014 at 11:04:53AM +0530, Amit Shah wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes the host to not

On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > added a call to rng_get_data() from the hwrng_register() function. > However, some rng devices need initialization before data can be read > from them. > > This commit makes the call to rng_get_data() depend on no init fn > pointer

On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > added a call to rng_get_data() from the hwrng_register() function. > However, some rng devices need initialization before data can be read > from them. > > This commit makes the call to rng_get_data() depend on no init fn > pointer

On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: > Hi Jason, > > On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > added a call to rng_get_data() from the hwrng_register() function. > > However, some rng devices need initialization before data can be read > >

On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: > Hi Jason, > > On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > added a call to rng_get_data() from the hwrng_register() function. > > However, some rng devices need initialization before data can be read > >

Commit d9e7972619334 "hwrng: add randomness to system from rng sources" added a call to rng_get_data() from the hwrng_register() function. However, some rng devices need initialization before data can be read from them. Also, the virtio-rng device does not behave properly when this call is made in its probe() routine - the virtio core sets the DRIVER_OK status bit only on a successful

On Wed, Jul 02, 2014 at 03:58:15PM +0530, Amit Shah wrote: > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > added a call to rng_get_data() from the hwrng_register() function. > However, some rng devices need initialization before data can be read > from them. > > Also, the virtio-rng device does not behave properly when this call is > made

On Wed, Jul 02, 2014 at 03:58:15PM +0530, Amit Shah wrote: > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > added a call to rng_get_data() from the hwrng_register() function. > However, some rng devices need initialization before data can be read > from them. > > Also, the virtio-rng device does not behave properly when this call is > made

On Wed, Jul 09, 2014 at 06:38:22PM +0530, Amit Shah wrote: > On (Wed) 09 Jul 2014 [07:53:17], Jason Cooper wrote: > > On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > > added a call to rng_get_data() from the hwrng_register() function. > > > However, some rng

On Wed, Jul 09, 2014 at 06:38:22PM +0530, Amit Shah wrote: > On (Wed) 09 Jul 2014 [07:53:17], Jason Cooper wrote: > > On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > > added a call to rng_get_data() from the hwrng_register() function. > > > However, some rng

On Mon, Jul 14, 2014 at 10:05:19AM +0530, Amit Shah wrote: > Some RNG devices may not be ready to give early randomness at probe() > time, and hence lose out on the opportunity to contribute to system > randomness at boot- or device hotplug- time. > > This commit schedules a delayed work item for such devices, and fetches > early randomness after a delay. Currently the delay is

On Mon, Jul 14, 2014 at 10:05:19AM +0530, Amit Shah wrote: > Some RNG devices may not be ready to give early randomness at probe() > time, and hence lose out on the opportunity to contribute to system > randomness at boot- or device hotplug- time. > > This commit schedules a delayed work item for such devices, and fetches > early randomness after a delay. Currently the delay is

http://bugzilla.mindrot.org/show_bug.cgi?id=65 Summary: TCP Wrappers support does not log successful connections Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org