There is such thing as a subsystem in (Open)SSH: it is a program which gets lauched when you request something other than interactive shell. Technically it is just an executable on remote host which is exec'd by sshd child after authenticating you and calling setuid.
You can locate a standard subsystem definition for sftp in your SSH config:
Subsystem sftp /usr/lib/openssh/sftp-server
As it is just a plain executable, not a SUID one or special in any other way, you can write a shell script that will change any attributes you need and then just launch original subsystem handler.
Place the following script into /usr/lib/openssh folder as e.g. sftp-fperm-server (this is not required, just to keep things in one place):
#!/bin/sh
umask 026
exec /usr/lib/openssh/sftp-server
Then add a line in the end of /etc/ssh/sshd_config:
Subsystem sftp-fperm /usr/lib/openssh/sftp-fperm-server
And then restart sshd (it does not kill sessions on restart) and launch sftp with a -s sftp-fperm option. Voila! files get the new specified umask.
If you do not want to specify that option each time, just change the standard subsystem definition. Interactive sessions won't be affected by it, so there are no chances of breaking somthing.
If you want to use the newgrp command, things will be a bit trickier. newgrp always launches a new interactive shell while stupidly don't allowing to pass any parameters to it, so you can't use it as the umask in previous example. But you can replace the last line in script with:
SHELL=/usr/lib/openssh/sftp-server newgrp git
Actually calling the newgrp for some group I belong to emits a password request, so I was unable to check this solution (I mean only the newgrp one), but it works when I pass the /bin/id on my laptop (without SSH), so if you got newgrp working for user no problems should arise.
Symlinks are essentially just pointers to another file, but you can't point
to something outside the chroot because it would be looking for a file with
that name which doesn't exist inside the chroot.
You could use mount with bind to remount the directories you need in
the jail.
For example:
# mount --bind /bin /chroot/bin
# mount --bind /lib /chroot/lib
# chroot /chroot
If you wish to place it in /etc/fstab, the same example would look like:
/bin /chroot/bin none bind
/lib /chroot/lib none bind
Best Answer
Apologies i do not have sufficent reputation here to post all the links inline. I have prepared a gist which preserves them: https://gist.github.com/3590779
There's no way to achieve this with simple permissions. Due to OpenSSH's sftp-server you won't be able to implement the full requirements list but depending on the filesystem the files are being uploaded to, you can leverage [attributes] and [ACLs] to achieve some of your requirements.
Yes, the [sftp-server takes a -u parameter] (you can set this in your [sshd_config] on the
Subsystem sftpline) which sets the umask for all uploads.Yes, you can make use of inotify, one way may be with the [incron] tool although there are many ways to use inotify. Inotify allows you to have the kernel notify a userspace program on a filesystem event you identify, e.g. adding a file to a directory. You can then run a command on this event.
(3 Part 2) An alternative approach that may not be suitable for you is to use something like vsftpd with SSL protected FTP. This allows for encrypted FTP but because vsftpd is a full featured FTP server it provides simple configuration (see the [chown_uploads parameter] in vsftpd.conf) to match your exact needs.
Yes, via the inotify subsystem, you could register a watch for the [IN_CLOSE_WRITE] event.