[SFTP] Possibility for Adding "ForceFilePermission" option

[House Lee]

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.