House Lee
2017-Dec-18 16:46 UTC
[SFTP] Possibility for Adding "ForceFilePermission" option
Hi Jakub, Sorry for the late reply. I was off from work for a few days. I?ve tried to add the noexec, nosuid and nodev mount options but it seems to have some difficulties to do so with kubernetes nfs-mount. I?ll keep trying to resolve it anyway. The patch you pasted is exactly the thing I wanna have. I think it?s super useful and I definitely vote yes for merging it to master. I was actually planning to create a patch myself if not seeing your reply. Is it possible to raise a concern about this patch in the developer group? Regarding the ?a script that fixes file permissions upon upload?, this is also an interesting idea. But how do I add a hook that is listening to the upload events? Thanks & Best Regards House> On Dec 18, 2017, at 06:03, Jakub Jelen <jjelen at redhat.com> wrote: > > On Thu, 2017-12-14 at 10:26 -0600, House Lee wrote: >> Hi, >> >> I understand that if I specify `ForceCommand internal-sftp -u >> <umask>`, the permission of any files uploaded via sftp will be >> calculated by `<original permission> & ~umask`. However, this can be >> bypassed by the `-P` option of `put` command. We are developing a >> shared hosting platform, therefore we definitely don?t want our users >> being able to upload any executable files. We can not disable the x >> permission by umask because directories need the x permission. >> >> Is there any possible way to accomplish this? or is it possible to >> add a `ForceFilePermission` and `ForceDirPermission` option in the >> sshd_config ? >> >> Thanks & Best Regards, >> House > > > Hello, > during last month, there were already two emails in this mailing list > discussing this issue: > > https://lists.mindrot.org/pipermail/openssh-unix-dev/2017- > November/036468.html > > The patch exists here since 2010 and it is currently used in > Fedora/RHEL to a great satisfaction, though it was never accepted by > upstream nor there was any official statement if they will eventually > accept this change or why not (and in which I would be greatly > interested). > > Best advise I have is to pull that patch from the linked thread above. > Or have some script that is fixing the files permissions upon upload. > > Regards, > Jakub > > -- > Jakub Jelen > Software Engineer > Security Technologies > Red Hat, Inc.
Jakub Jelen
2017-Dec-19 09:03 UTC
[SFTP] Possibility for Adding "ForceFilePermission" option
On Mon, 2017-12-18 at 10:46 -0600, House Lee wrote:> Hi Jakub, > > Sorry for the late reply. I was off from work for a few days. > > I?ve tried to add the noexec, nosuid and nodev mount options but it > seems to have some difficulties to do so with kubernetes nfs-mount. > I?ll keep trying to resolve it anyway. > > The patch you pasted is exactly the thing I wanna have. I think it?s > super useful and I definitely vote yes for merging it to master. I > was actually planning to create a patch myself if not seeing your > reply. Is it possible to raise a concern about this patch in the > developer group?Best way to make a contact with OpenSSH developers is probably this mailing list or a bugzilla.> Regarding the ?a script that fixes file permissions upon upload?, > this is also an interesting idea. But how do I add a hook that is > listening to the upload events?There is no way to add hooks into the stock sftp-server. But you can create hooks directly to the filesystem using inotify (though I am not sure about containers support). Other possibility could be a script that is running after the client disconnects (such as "ForceCommand internal-sftp;/usr/local/bin/fix- modes.sh"), but in that case you would still have there an open window with "bad" permissions. Regards, Jakub> > Thanks & Best Regards > House > > > > On Dec 18, 2017, at 06:03, Jakub Jelen <jjelen at redhat.com> wrote: > > > > On Thu, 2017-12-14 at 10:26 -0600, House Lee wrote: > > > Hi, > > > > > > I understand that if I specify `ForceCommand internal-sftp -u > > > <umask>`, the permission of any files uploaded via sftp will be > > > calculated by `<original permission> & ~umask`. However, this can > > > be > > > bypassed by the `-P` option of `put` command. We are developing a > > > shared hosting platform, therefore we definitely don?t want our > > > users > > > being able to upload any executable files. We can not disable the > > > x > > > permission by umask because directories need the x permission. > > > > > > Is there any possible way to accomplish this? or is it possible > > > to > > > add a `ForceFilePermission` and `ForceDirPermission` option in > > > the > > > sshd_config ? > > > > > > Thanks & Best Regards, > > > House > > > > > > Hello, > > during last month, there were already two emails in this mailing > > list > > discussing this issue: > > > > https://lists.mindrot.org/pipermail/openssh-unix-dev/2017- > > November/036468.html > > > > The patch exists here since 2010 and it is currently used in > > Fedora/RHEL to a great satisfaction, though it was never accepted > > by > > upstream nor there was any official statement if they will > > eventually > > accept this change or why not (and in which I would be greatly > > interested). > > > > Best advise I have is to pull that patch from the linked thread > > above. > > Or have some script that is fixing the files permissions upon > > upload. > > > > Regards, > > Jakub > > > > -- > > Jakub Jelen > > Software Engineer > > Security Technologies > > Red Hat, Inc. > >-- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc.
House Lee
2017-Dec-19 16:53 UTC
[SFTP] Possibility for Adding "ForceFilePermission" option
I guess inotify can not be an option since we need to monitoring the whole file system, that being said, we are monitoring millions of files. This has 2 potential problems that I?m not sure with: 1. inotify doesn?t support recursive monitor, we will have to recursively add a watcher for each subdirectories. Therefore, this might result in millions of inotify watchers, can OS support such a large number of inotify watchers? 2. Even if the OS can handle such a huge amount of watchers, but will it still be efficient when handling so many watchers and watching so many files? Send from my iPhone House> On Dec 19, 2017, at 03:03, Jakub Jelen <jjelen at redhat.com> wrote: > > On Mon, 2017-12-18 at 10:46 -0600, House Lee wrote: >> Hi Jakub, >> >> Sorry for the late reply. I was off from work for a few days. >> >> I?ve tried to add the noexec, nosuid and nodev mount options but it >> seems to have some difficulties to do so with kubernetes nfs-mount. >> I?ll keep trying to resolve it anyway. >> >> The patch you pasted is exactly the thing I wanna have. I think it?s >> super useful and I definitely vote yes for merging it to master. I >> was actually planning to create a patch myself if not seeing your >> reply. Is it possible to raise a concern about this patch in the >> developer group? > > Best way to make a contact with OpenSSH developers is probably this > mailing list or a bugzilla. > >> Regarding the ?a script that fixes file permissions upon upload?, >> this is also an interesting idea. But how do I add a hook that is >> listening to the upload events? > > There is no way to add hooks into the stock sftp-server. But you can > create hooks directly to the filesystem using inotify (though I am not > sure about containers support). > > Other possibility could be a script that is running after the client > disconnects (such as "ForceCommand internal-sftp;/usr/local/bin/fix- > modes.sh"), but in that case you would still have there an open window > with "bad" permissions. > > Regards, > Jakub > >> >> Thanks & Best Regards >> House >> >> >>> On Dec 18, 2017, at 06:03, Jakub Jelen <jjelen at redhat.com> wrote: >>> >>> On Thu, 2017-12-14 at 10:26 -0600, House Lee wrote: >>>> Hi, >>>> >>>> I understand that if I specify `ForceCommand internal-sftp -u >>>> <umask>`, the permission of any files uploaded via sftp will be >>>> calculated by `<original permission> & ~umask`. However, this can >>>> be >>>> bypassed by the `-P` option of `put` command. We are developing a >>>> shared hosting platform, therefore we definitely don?t want our >>>> users >>>> being able to upload any executable files. We can not disable the >>>> x >>>> permission by umask because directories need the x permission. >>>> >>>> Is there any possible way to accomplish this? or is it possible >>>> to >>>> add a `ForceFilePermission` and `ForceDirPermission` option in >>>> the >>>> sshd_config ? >>>> >>>> Thanks & Best Regards, >>>> House >>> >>> >>> Hello, >>> during last month, there were already two emails in this mailing >>> list >>> discussing this issue: >>> >>> https://lists.mindrot.org/pipermail/openssh-unix-dev/2017- >>> November/036468.html >>> >>> The patch exists here since 2010 and it is currently used in >>> Fedora/RHEL to a great satisfaction, though it was never accepted >>> by >>> upstream nor there was any official statement if they will >>> eventually >>> accept this change or why not (and in which I would be greatly >>> interested). >>> >>> Best advise I have is to pull that patch from the linked thread >>> above. >>> Or have some script that is fixing the files permissions upon >>> upload. >>> >>> Regards, >>> Jakub >>> >>> -- >>> Jakub Jelen >>> Software Engineer >>> Security Technologies >>> Red Hat, Inc. >> >> > -- > Jakub Jelen > Software Engineer > Security Technologies > Red Hat, Inc.