10 Oct
2014
10 Oct
'14
9:51 p.m.
All,
I am in a bit of a time-bind and am wondering if anyone could help me
with this. Namely, I am trying to cobble a sftp system where conference
participants may want to upload their proposed submissions and once they
are uploaded that they are unable to delete their own or anyone else's
submission. Going with commercial solutions is not an option.
So, what I did so far is change /etc/ssh/sshd_config so that sftp
chroots said user's home dir, and prevents access via ssh. I also
created a sftponly group and added the user to it. I adjusted home dir
permissions and created a subfolder "submissions" where users can submit
their projects. Finally, I added umask to strip permissions from
uploaded files.
So, the /etc/ssh/sshd_config has the following entry
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp -u 0222
X11Forwarding no
AllowTcpForwarding no
So, everything works, except no matter what permissions assign via
umask, even if I change ownership manually via a different ssh user
session, sftp client can still erase the file. How is this possible? And
more importantly, how can one circumvent that? And perhaps most
importantly is there an easier way to do this?
Below are permissions of folders in question:
drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .
drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..
drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions
Any idea how this can be fixed?
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
10 Oct
10 Oct
10:01 p.m.
On Fri, 10 Oct 2014 15:51:29 -0400
Ivica Ico Bukvic <ico(a)vt.edu> wrote:
So, what I did so far is change /etc/ssh/sshd_config
so that sftp
chroots said user's home dir, and prevents access via ssh. I also
created a sftponly group and added the user to it. I adjusted home dir
permissions and created a subfolder "submissions" where users can submit
their projects. Finally, I added umask to strip permissions from
uploaded files.
So, the /etc/ssh/sshd_config has the following entry
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp -u 0222
X11Forwarding no
AllowTcpForwarding no
What's your subsystem line look like? You can force the umask there with
the -u directive. Example:
Subsystem sftp /usr/libexec/openssh/sftp-server -u 0002
If your sftp-server does not support -u then you can get the same effect
with this:
Subsystem sftp /bin/sh -c 'umask 0002; /usr/lib/openssh/sftp-server'
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
11:06 p.m.
On 10/10/2014 04:01 PM, Joe Hartley wrote:
On Fri, 10 Oct 2014 15:51:29 -0400
Ivica Ico Bukvic <ico(a)vt.edu> wrote:
Thanks for this but I thought that is what ForceCommand internal-sftp -u
0222 does (and it does change file permissions except that even if
permissions are 000 I can still delete the file through sftp.
Subsystem is
Subsystem sftp /usr/lib/openssh/sftp-server
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts - 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
So, what I did so far is change
/etc/ssh/sshd_config so that sftp
chroots said user's home dir, and prevents access via ssh. I also
created a sftponly group and added the user to it. I adjusted home dir
permissions and created a subfolder "submissions" where users can submit
their projects. Finally, I added umask to strip permissions from
uploaded files.
So, the /etc/ssh/sshd_config has the following entry
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp -u 0222
X11Forwarding no
AllowTcpForwarding no
What's your subsystem line look like? You can force the
umask there with
the -u directive. Example:
Subsystem sftp /usr/libexec/openssh/sftp-server -u 0002
If your sftp-server does not support -u then you can get the same effect
with this:
Subsystem sftp /bin/sh -c 'umask 0002; /usr/lib/openssh/sftp-server'
11:07 p.m.
On 10/10/2014 05:06 PM, Ivica Ico Bukvic wrote:
On 10/10/2014 04:01 PM, Joe Hartley wrote:
Also, the problem with this issue is that this needs to be specific to
one user, not system-wide, hence my preference of ForceCommand...
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts - 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
On Fri, 10 Oct 2014 15:51:29 -0400
Ivica Ico Bukvic <ico(a)vt.edu> wrote:
Thanks for this but I thought that is what ForceCommand internal-sftp
-u 0222 does (and it does change file permissions except that even if
permissions are 000 I can still delete the file through sftp.
Subsystem is
Subsystem sftp /usr/lib/openssh/sftp-server
So, what I did so far is change
/etc/ssh/sshd_config so that sftp
chroots said user's home dir, and prevents access via ssh. I also
created a sftponly group and added the user to it. I adjusted home dir
permissions and created a subfolder "submissions" where users can
submit
their projects. Finally, I added umask to strip permissions from
uploaded files.
So, the /etc/ssh/sshd_config has the following entry
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp -u 0222
X11Forwarding no
AllowTcpForwarding no
What's your subsystem line look like? You can force the
umask there
with
the -u directive. Example:
Subsystem sftp /usr/libexec/openssh/sftp-server -u 0002
If your sftp-server does not support -u then you can get the same effect
with this:
Subsystem sftp /bin/sh -c 'umask 0002; /usr/lib/openssh/sftp-server'
10:05 p.m.
On 10/10/2014 12:51 PM, Ivica Ico Bukvic wrote:
All,
I am in a bit of a time-bind and am wondering if anyone could help me
with this. Namely, I am trying to cobble a sftp system where conference
participants may want to upload their proposed submissions and once they
are uploaded that they are unable to delete their own or anyone else's
submission. Going with commercial solutions is not an option.
So, what I did so far is change /etc/ssh/sshd_config so that sftp
chroots said user's home dir, and prevents access via ssh. I also
created a sftponly group and added the user to it. I adjusted home dir
permissions and created a subfolder "submissions" where users can submit
their projects. Finally, I added umask to strip permissions from
uploaded files.
So, the /etc/ssh/sshd_config has the following entry
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp -u 0222
X11Forwarding no
AllowTcpForwarding no
So, everything works, except no matter what permissions assign via
umask, even if I change ownership manually via a different ssh user
session, sftp client can still erase the file. How is this possible? And
delete is an operation on directory, meaning they can delete file if
they have write access to directory which they need to be able to create
files.
more importantly, how can one circumvent that? And
perhaps most
importantly is there an easier way to do this?
seem like you can whitelist and blacklist sftp commands, so just
don't allow delete? See man sftp and -p and -P options. Didn't actually
try it but it seems like it would do what you want.
erik
Below are permissions of folders in question:
drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .
drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..
drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions
Any idea how this can be fixed?
11:11 p.m.
On 10/10/2014 04:05 PM, Erik Steffl wrote:
How would I go about doing that only for a specific user? Where would I
store/change such sftp options?
On 10/10/2014 12:51 PM, Ivica Ico Bukvic wrote:
Except how can one do this via sftp even if the file permission has been
changed 000 (meaning no permissions)? Via ssh that is not the case at
all and I thought that sftp's backend is ssh?
All,
I am in a bit of a time-bind and am wondering if anyone could help me
with this. Namely, I am trying to cobble a sftp system where conference
participants may want to upload their proposed submissions and once they
are uploaded that they are unable to delete their own or anyone else's
submission. Going with commercial solutions is not an option.
So, what I did so far is change /etc/ssh/sshd_config so that sftp
chroots said user's home dir, and prevents access via ssh. I also
created a sftponly group and added the user to it. I adjusted home dir
permissions and created a subfolder "submissions" where users can submit
their projects. Finally, I added umask to strip permissions from
uploaded files.
So, the /etc/ssh/sshd_config has the following entry
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp -u 0222
X11Forwarding no
AllowTcpForwarding no
So, everything works, except no matter what permissions assign via
umask, even if I change ownership manually via a different ssh user
session, sftp client can still erase the file. How is this possible? And
delete is an operation on directory, meaning they can delete file if
they have write access to directory which they need to be able to
create files. more importantly, how can one circumvent that?
And perhaps most
importantly is there an easier way to do this?
seem like you can whitelist and blacklist sftp commands, so just
don't allow delete? See man sftp and -p and -P options. Didn't
actually try it but it seems like it would do what you want.
erik
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts - 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
Below are permissions of folders in question:
drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .
drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..
drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions
Any idea how this can be fixed?
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user 
11:08 p.m.
On Fri, 10 Oct 2014, Ivica Ico Bukvic wrote:
So, everything works, except no matter what
permissions assign via umask,
even if I change ownership manually via a different ssh user session, sftp
client can still erase the file. How is this possible? And more importantly,
how can one circumvent that? And perhaps most importantly is there an easier
way to do this?
Below are permissions of folders in question:
drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .
drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..
drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions
Any idea how this can be fixed?
I don't know how easy it would be to do, but on uploading, create a hard
link to a file in a directory on the same drive where the user does not
have access. The hard link can have a different owner/permitions. Once the
upload is complete, unlink the original uploaded file. This is effectively
a mv, but with owner/permitions changed. The file doesn't have to be fully
uploaded before the link is created so long as the filename is already in
the directory.... but watch for an sftp client that uploads under an
upload name, but creates a zero length file with the final uploaded name
to save the file name on the disk and then mv the uploaded file to that
name. You may have to look for both names. (they are normally similar) You
could write a simple service that just watches the upload directory for
new files and fixes them that way.
--
Len Ovens
www.ovenwerks.net
11:12 p.m.
On 10/10/2014 05:08 PM, Len Ovens wrote:
On Fri, 10 Oct 2014, Ivica Ico Bukvic wrote:
Thanks for the advice. This, however, needs to be as automated as
possible, meaning we give access to submitter and they do it all themselves.
So, everything works, except no matter what
permissions assign via
umask, even if I change ownership manually via a different ssh user
session, sftp client can still erase the file. How is this possible?
And more importantly, how can one circumvent that? And perhaps most
importantly is there an easier way to do this?
Below are permissions of folders in question:
drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .
drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..
drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions
Any idea how this can be fixed?
I don't know how easy it would be to do, but on uploading, create a
hard link to a file in a directory on the same drive where the user
does not have access. The hard link can have a different
owner/permitions. Once the upload is complete, unlink the original
uploaded file. This is effectively a mv, but with owner/permitions
changed. The file doesn't have to be fully uploaded before the link is
created so long as the filename is already in the directory.... but
watch for an sftp client that uploads under an upload name, but
creates a zero length file with the final uploaded name to save the
file name on the disk and then mv the uploaded file to that name. You
may have to look for both names. (they are normally similar) You could
write a simple service that just watches the upload directory for new
files and fixes them that way.
--
Len Ovens
www.ovenwerks.net
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts - 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
11:46 p.m.
On Fri, 10 Oct 2014, Ivica Ico Bukvic wrote:
On 10/10/2014 05:08 PM, Len Ovens wrote:
It is automated. A script (bash, perl, python, whatever) is created in the
form:
----------------------8<---------------
$time = time
while 1 {
if (directory modified since $time)
look for files created since time.
check if upload is complete
create hard link to another directory
set perm
unlink uploaded file
$time = time
wait a second (save cpu cycles)
}
-------------------8<------------------
Run this from /etc/init.d
It may be simpler to watch a log file looking for sftp files that have
been uploaded to that directory by running /log/logfile through tail -f
and parsing.
It should run as a different user than any login name (no password) and
the directory/files should be read only by anyone else.
Just a thought, does changing the owner of the file as well as perm have
any effect? Generally the owner of a readonly file can still delete it. rm
asks first, sftp may not. The owner can change the write bit for their own
file and sftp may try to do so and delete if successful.
--
Len Ovens
www.ovenwerks.net
On Fri, 10 Oct 2014, Ivica Ico Bukvic wrote:
Thanks for the advice. This, however, needs to be as automated as possible,
meaning we give access to submitter and they do it all themselves. So, everything works, except no matter what
permissions assign via umask,
even if I change ownership manually via a different ssh user session, sftp
client can still erase the file. How is this possible? And more
importantly, how can one circumvent that? And perhaps most importantly is
there an easier way to do this?
Below are permissions of folders in question:
drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .
drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..
drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions
Any idea how this can be fixed?
I don't know how easy it would be to do, but on uploading, create a hard
link to a file in a directory on the same drive where the user does not
have access. The hard link can have a different owner/permitions. Once the
upload is complete, unlink the original uploaded file. This is effectively
a mv, but with owner/permitions changed. The file doesn't have to be fully
uploaded before the link is created so long as the filename is already in
the directory.... but watch for an sftp client that uploads under an upload
name, but creates a zero length file with the final uploaded name to save
the file name on the disk and then mv the uploaded file to that name. You
may have to look for both names. (they are normally similar) You could
write a simple service that just watches the upload directory for new files
and fixes them that way. 
11 Oct
11 Oct
12:34 p.m.
New subject: OT: seeking help with uploading files via sftp and preventing their subsequent deletion
On Fri, Oct 10, 2014 at 03:51:29PM -0400, Ivica Ico Bukvic wrote:
All,
I am in a bit of a time-bind and am wondering if anyone could help me
with this. Namely, I am trying to cobble a sftp system where conference
participants may want to upload their proposed submissions and once they
are uploaded that they are unable to delete their own or anyone else's
submission. Going with commercial solutions is not an option.
So, what I did so far is change /etc/ssh/sshd_config so that sftp
chroots said user's home dir, and prevents access via ssh. I also
created a sftponly group and added the user to it. I adjusted home dir
permissions and created a subfolder "submissions" where users can submit
their projects. Finally, I added umask to strip permissions from
uploaded files.
So, the /etc/ssh/sshd_config has the following entry
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp -u 0222
X11Forwarding no
AllowTcpForwarding no
So, everything works, except no matter what permissions assign via
umask, even if I change ownership manually via a different ssh user
session, sftp client can still erase the file. How is this possible? And
more importantly, how can one circumvent that? And perhaps most
importantly is there an easier way to do this?
Below are permissions of folders in question:
drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .
drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..
drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions
Any idea how this can be fixed?
An idea is to remove the destructive commands in sftp-server
and open a file in write mode only with the file creation flags
O_CREAT and O_EXCL, so it is impossible to overwrite a file.
A patch (no tested) for sftp-server.c (openssh 6) is
--- sftp-server.c~ 2014-10-11 12:18:32.357980133 +0200
+++ sftp-server.c 2014-10-11 12:18:32.357980133 +0200
@@ -124,16 +124,14 @@
if ((pflags & SSH2_FXF_READ) &&
(pflags & SSH2_FXF_WRITE)) {
- flags = O_RDWR;
+ flags = O_RDWR | O_CREAT | O_EXCL;
} else if (pflags & SSH2_FXF_READ) {
flags = O_RDONLY;
} else if (pflags & SSH2_FXF_WRITE) {
- flags = O_WRONLY;
+ flags = O_WRONLY | O_CREAT | O_EXCL;
}
if (pflags & SSH2_FXF_CREAT)
flags |= O_CREAT;
- if (pflags & SSH2_FXF_TRUNC)
- flags |= O_TRUNC;
if (pflags & SSH2_FXF_EXCL)
flags |= O_EXCL;
return flags;
@@ -1316,10 +1314,7 @@
process_fstat();
break;
case SSH2_FXP_SETSTAT:
- process_setstat();
- break;
case SSH2_FXP_FSETSTAT:
- process_fsetstat();
break;
case SSH2_FXP_OPENDIR:
process_opendir();
@@ -1328,13 +1323,11 @@
process_readdir();
break;
case SSH2_FXP_REMOVE:
- process_remove();
break;
case SSH2_FXP_MKDIR:
process_mkdir();
break;
case SSH2_FXP_RMDIR:
- process_rmdir();
break;
case SSH2_FXP_REALPATH:
process_realpath();
@@ -1343,7 +1336,6 @@
process_stat();
break;
case SSH2_FXP_RENAME:
- process_rename();
break;
case SSH2_FXP_READLINK:
process_readlink();
@@ -1352,7 +1344,6 @@
process_symlink();
break;
case SSH2_FXP_EXTENDED:
- process_extended();
break;
default:
error("Unknown message %d", type);
4:14 p.m.
Thank you all for your responses. I finally opted for going the vsftpd
route which has a much more finely grained approach to this.
On Oct 11, 2014 6:34 AM, "Tito Latini" <tito.01beta(a)gmail.com> wrote:
On Fri, Oct 10, 2014 at 03:51:29PM -0400, Ivica Ico
Bukvic wrote:
All,
I am in a bit of a time-bind and am wondering if anyone could help me
with this. Namely, I am trying to cobble a sftp system where conference
participants may want to upload their proposed submissions and once they
are uploaded that they are unable to delete their own or anyone else's
submission. Going with commercial solutions is not an option.
So, what I did so far is change /etc/ssh/sshd_config so that sftp
chroots said user's home dir, and prevents access via ssh. I also
created a sftponly group and added the user to it. I adjusted home dir
permissions and created a subfolder "submissions" where users can submit
their projects. Finally, I added umask to strip permissions from
uploaded files.
So, the /etc/ssh/sshd_config has the following entry
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp -u 0222
X11Forwarding no
AllowTcpForwarding no
So, everything works, except no matter what permissions assign via
umask, even if I change ownership manually via a different ssh user
session, sftp client can still erase the file. How is this possible? And
more importantly, how can one circumvent that? And perhaps most
importantly is there an easier way to do this?
Below are permissions of folders in question:
drwxr-xr-x 3 root USER 4096 Oct 10 15:21 .
drwxr-xr-x 36 root root 4096 Oct 7 12:16 ..
drwxr-xr-x 2 USER sftponly 4096 Oct 10 19:39 submissions
Any idea how this can be fixed?
An idea is to remove the destructive commands in sftp-server
and open a file in write mode only with the file creation flags
O_CREAT and O_EXCL, so it is impossible to overwrite a file.
A patch (no tested) for sftp-server.c (openssh 6) is
--- sftp-server.c~ 2014-10-11 12:18:32.357980133 +0200
+++ sftp-server.c 2014-10-11 12:18:32.357980133 +0200
@@ -124,16 +124,14 @@
if ((pflags & SSH2_FXF_READ) &&
(pflags & SSH2_FXF_WRITE)) {
- flags = O_RDWR;
+ flags = O_RDWR | O_CREAT | O_EXCL;
} else if (pflags & SSH2_FXF_READ) {
flags = O_RDONLY;
} else if (pflags & SSH2_FXF_WRITE) {
- flags = O_WRONLY;
+ flags = O_WRONLY | O_CREAT | O_EXCL;
}
if (pflags & SSH2_FXF_CREAT)
flags |= O_CREAT;
- if (pflags & SSH2_FXF_TRUNC)
- flags |= O_TRUNC;
if (pflags & SSH2_FXF_EXCL)
flags |= O_EXCL;
return flags;
@@ -1316,10 +1314,7 @@
process_fstat();
break;
case SSH2_FXP_SETSTAT:
- process_setstat();
- break;
case SSH2_FXP_FSETSTAT:
- process_fsetstat();
break;
case SSH2_FXP_OPENDIR:
process_opendir();
@@ -1328,13 +1323,11 @@
process_readdir();
break;
case SSH2_FXP_REMOVE:
- process_remove();
break;
case SSH2_FXP_MKDIR:
process_mkdir();
break;
case SSH2_FXP_RMDIR:
- process_rmdir();
break;
case SSH2_FXP_REALPATH:
process_realpath();
@@ -1343,7 +1336,6 @@
process_stat();
break;
case SSH2_FXP_RENAME:
- process_rename();
break;
case SSH2_FXP_READLINK:
process_readlink();
@@ -1352,7 +1344,6 @@
process_symlink();
break;
case SSH2_FXP_EXTENDED:
- process_extended();
break;
default:
error("Unknown message %d", type);
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3698
days inactive
3699
days old
linux-audio-user@lists.linuxaudio.org
10 comments
6 participants
participants (6)
-
Erik Steffl -
Ivica Bukvic -
Ivica Ico Bukvic
-
Joe Hartley -
Len Ovens -
Tito Latini