similar to: [PATCH 8/12] openssh-4.3p2 return code check bugs

Sorry to repost, but I finally have the code on a machine that has diff -u, and I've updated it for 2.9p2. Attached is the unified diff to add logging of SFTP activity to auth.info. If there is a more proper way to contrib patches, please let me know. Cheers, Jason # "Jason A. Dour" <jason at dour.org> http://dour.org/ # Founder / Executive Producer - PJ

There are a couple of races in sftp-server as this patch shows: --- sftp-server.c 28 Jan 2003 18:06:53 -0000 1.1.1.2 +++ sftp-server.c 5 Feb 2003 19:19:42 -0000 @@ -832,19 +832,22 @@ process_rename(void) { u_int32_t id; - struct stat st; char *oldpath, *newpath; - int ret, status = SSH2_FX_FAILURE; + int status; id = get_int(); oldpath = get_string(NULL); newpath = get_string(NULL);

This is another take on logging for sftp-server. Given the number of private email requests I've received for this patch, I assume there is signifigant enough interest to request it be reviewed for inclusion into the release. The patch is against 3.1p1, and is completely disabled by default. To enable logging, one must use compile time directives (-DSFTP_LOGGING). This was done due to prior

Hi, please find a patch against openssh-4.7p1 This patch: 1) Allows for an optional configuration file 2) Allows a user to be restricted to a directory and it's children. Enjoy -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information:

Hi, Thanks a lot for this great software :) I'm trying to do something to secure my server. I need to disable removing file or removing directory using SFTP. In other words, the user can only write, move but not delete the file. This will be used to store logs so, I need to make sure once the logs written to my server the user cannot remove it. I tried doing this by changing the code of

This patch adds a readonly mode to scp and sftp_server. This allows clients to only read files from the server, but not to write them. Patch is based on OpenSSH 3.4p1 *** scp.c@@\main\1 Tue Oct 1 17:25:16 2002 --- scp.c Wed Oct 2 06:05:14 2002 *************** *** 122,127 **** --- 122,130 ---- /* This is set to zero if the progressmeter is not desired. */ int showprogress = 1; + /* deny

Hi, I submitted this a few weeks ago but here it is again since I got no response. If there is somewhere else I should send this, please tell me. This patch implements SSH2_FXF_APPEND in the sftp server. It is a fairly trivial patch and applies against the proper OpenSSH and the Portable edition. I would argue that it is important for OpenSSH to implement SSH2_FXF_APPEND since it is in the

I'm working on setting up a semi-trusted sftp service, and to get it working, I need chroot capability. I've taken the /./ wuftpd magic token code from contrib/chroot.diff and put it into the sftp server. The main problem is that privileges have been dropped by the time the subsystem is exec'ed, so my patch requires that sftp-server be setuid root. Not ideal, I know, but I drop all

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

And while we are at it, can you please comment on these patches as well, originally submitted around one year ago. Oh, and I think we can agree, that the secsh-filexfer standardization is dead, so there's not much point in trying to support newer protocol versions, which don't have statfs anyway. Thanks, Miklos ----- This is needed to be able to support statfs operation on an SSH

Hi everyone I would like to enable unprivileged users to share only certain directories using SFTP without acquiring root, without setting capabilities using public-key-based forced commands. In another use case unprivileged users could write scripts that evaluate "$SSH_ORIGINAL_COMMAND" and then either execute sftp-server in a jail "$SSH_ORIGINAL_COMMAND" after

Hi, I've already discussed this issue in SSHSCI's SSH 2.2 context on ssh at clinet.fi list. My standpoint is that it's wrong and meaningless to perform chown in sftp-server as the file is most likely copied between systems with distinct accounting system where user is not necessarily (and even unlikely) has same numeric user id. The original bug report was that user couldn't

One of the features missing in sftp is the ability to transfer a symlink. This patch adds a new command to sftp which performs this transfer. Note that it uses messages that already exist in the protocol between client and server. This diff is based on OpenSSH 3.4p1. *** sftp-client.c@@\main\1 Tue Oct 1 17:26:20 2002 --- sftp-client.c Wed Oct 23 15:57:34 2002 *************** *** 666,672 ****

Here's a patch that adds support for the creation of hard links over SFTP. Hard links are not used very often nowdays, but they do still have their uses and this is currently the most often requested improvement for SSHFS. To detect hard links the st_nlink, st_dev and st_ino attributes are usually used. I'll also post patches adding extensions for these and other attributes. Please

This is needed to be able to support a rename() operation conforming to POSIX in the SSH filesystem. With the rename operation defined in the SFTP spec, this is impossible, since in case the target exists it's not possible to perform the rename+unlink atomically. Miklos Index: ssh/sftp-server.c =================================================================== --- ssh.orig/sftp-server.c

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 needed to be able to support statfs operation on an SSH filesystem (http://fuse.sourceforge.net/sshfs.html). It uses and sends only those fields of struct statfs which are common with struct statvfs as defined by POSIX, and which are shared among most UNIX-like systems. The SSH_FXP_EXTENDED message type is used, so this change is backward compatible and conforms to the protocol

Hi, I've discovered that on OpenSSH_3.6.1p1 (the latest SSH available on OSX, but I've also tried a couple of different linux distributions), when you 'sftp' to it, and try to 'chmod' some file or directory, only last three octal digits do actually matter. Example: sftp sshtest at localhost Connecting to localhost... sshtest at localhost's password: sftp> ls -l

Hi All, After configuring and compiling OpenSSH version 4.6p1 in my SUN Solaris8 ultrasparc machine, I run "make tests" and got the following errors. The compiler used is GCC3.3. run test sftp.sh ... test basic sftp put/get: buffer_size 5 num_requests 1 sftp failed with 1 test basic sftp put/get: buffer_size 5 num_requests 2 sftp failed with 1 test basic sftp put/get: buffer_size 5

Hello, Couple of days ago, I received a request from a customer. He wants to provide sftp users access to a directory tree containing files. The users must have full rights, but he also wants to avoid moving or deleting directories. This is mostly to prevent mistakenly drag and drop from user's graphical client (Filezilla). Said differently, he wants to protect the directories organization.