similar to: ssh(1) multiplexing rewrite

Attached (and inline) is a patch to add the following config options: ControlBindMask ControlAllowUsers ControlAllowGroups ControlDenyUsers ControlDenyGroups It pulls the peer credential check from client_process_control() in ssh.c, and expounds upon it in a new function, client_control_grant(). Supplemental groups are not checked in this patch. I didn't feel comfortable taking a shot

The variable cmd is xmalloc'd by buffer_get_string. It is then used in some places but never freed. This patch places the xfree after the last usage and within the confines of all paths. This entire set of patches passed the regression tests on my system. Memory leak bug found by Coverity. Signed-off-by: Kylene Hall <kjhall at us.ibm.com> --- clientloop.c | 2 ++ 1 files changed,

Hi all, currently I am considering writing a patch for OpenSSH that will allow portforwarding using the control_master unix domain socket. The idea is to introduce an extra SSHMUX command, SSHMUX_COMMAND_SOCKS, which will then pass control to the normal socks functions used for dynamic forwarding. The main reason for me to write this patch are: - some more control over who gets to connect to

I have renamed all of the patch files to .txt, which should be acceptable for the mailer daemon at mindrot, per Angel's suggestion. I am attaching the patch files to the email, with the extra space removed and a minor correction made. Bill Parker (wp02855 at gmail dot com) -------------- next part -------------- --- port-linux.c.orig 2012-12-19 17:40:53.231529475 -0800 +++ port-linux.c

Hello All, In reviewing source code for OpenSSH-6.1p1, I found instances of deprecated library calls still within various source code files. Examples of deprecated calls are: bzero() (replaced with memset() which is ANSI compliant), index() (replaced with strchr() which is also ANSI compliant). In file 'auth2-jpake.c', I've replaced all the bzero() calls with the equivalent

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

Hi all, This is a client side only implementation of reversed dynamic (SOCKS) TCP forwarding, which means it is compatible with any existing servers have 'remote forward' capability. To establish such forward, use "ssh -R [BIND_ADDRESS:]PORT ...". The server will listen on that port and address and accept SOCKS traffics. Hope this will be useful for you. There was an

This patch adds all the missing commonly used UNIX attributes: st_dev, st_ino, st_nlink, st_rdev, st_blocks, st_blksize, st_ctime. In addition it extends st_atime and st_mtime to 64bits, and adds nanosecond resolution to all three timestamps. This is implemented as an extension to the ATTR message. This patch alone is sufficient for SSHFS to be able to use these attributes. The following two

I'd like to propose the following extensions to the SFTP protocol. - statvfs operation - atomic rename (just plain POSIX rename() without the existence check) These are the most requested features in SSHFS, which need support in sftp-server too. They could be added to the current protocol with the SSH_FXP_EXTENDED message type. Here's a patch implementing the statvfs operation. It

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified

Hi! This is a issue that has been fixed in master, thank you for reporting. See https://github.com/dovecot/core/commit/187fbf157d5c42f9f06ce52884fefbb4f66c070d.patch Aki On 17.10.2017 21:12, Dmitry Nezhevenko wrote: > Hi, > > Can't find any notes about this in documentation. Is replication supposed > to work between different versions of dovecot? > > I've just found

Hi, Can't find any notes about this in documentation. Is replication supposed to work between different versions of dovecot? I've just found that dovecot 2.2.33.1 was uploaded to debian unstable and it crashes on every replication with older dovecot 2.2.27. (version 2.2.32.1 was probably ok) Summary: - 2.2.33.1 crashes when replicating from/to 2.2.27 - 2.2.32.1 probably ok when

Cheers, - Salva $ diff -c mux.c~ mux.c *** mux.c~ 2008-06-14 01:01:54.000000000 +0200 --- mux.c 2008-12-04 12:24:45.000000000 +0100 *************** *** 148,153 **** --- 148,154 ---- error("ControlSocket %s already exists, " "disabling multiplexing", options.control_path); close(muxserver_sock); + umask(old_umask);

--- mux.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mux.c b/mux.c index d90605e..fa796bd 100644 --- a/mux.c +++ b/mux.c @@ -1195,6 +1195,7 @@ muxserver_listen(void) close(muxserver_sock); muxserver_sock = -1; } + xfree(orig_control_path); xfree(options.control_path); options.control_path = NULL; options.control_master = SSHCTL_MASTER_NO;

Hello, I had some difficulties in order to convert private keys between different implementations of SSH. So, I wrote the following patch to allow export of SSH2 RSA and DSA private keys into IETF SECSH format. Note that I also slightly revised the IETF SECSH key import code. Usage: use of the "-e" option on a private key file generates an unencrypted private key file in IETF SECSH

Hello, coredump found after a force-resync and a replicate Emmanuel. (dovecot-ee 2.2.30.2-1) [New LWP 17168] Core was generated by `dovecot/doveadm-server'. Program terminated with signal SIGABRT, Aborted. #0 0x00007fa334127c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #0 0x00007fa334127c37 in __GI_raise (sig=sig at entry=6) at

Hi, during the store of the messages, I find the following doveadm errors: 2019-10-02 09:22:19 auth: Debug: ldap(test.pop at test.xxx.it,10.11.47.60<mailto:test.pop at test.xxx.it,10.11.47.60>): result: mailMessageStore=1/1/2/0/8/7/2/1120872_91093 mailQuota=52428800; mailQuota,mailMessageStore unused 2019-10-02 09:22:19 auth: Debug: ldap(test.pop at