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@xxxxxxxxxx> 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@xxxxxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
