-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using mod_facl and mod_vroot at same time causes unexpected permissions issues #1780
Comments
I think this issue is similar to #1764 -- both
Fortunately, I think a similar solution can be used here, since |
Can you try out #1781, see if it addresses your issue? |
Hi @Castaglia,
Unfortunately, the result is still the same. All directories get filtered out and the trace gives again:
|
These are interesting:
I guess it is showing that |
Thanks for your efforts. So you suspect |
I'm not sure if it's only |
I built a new version that contains both of your modifications. The directories are still filtered out. The log looks a little bit different:
|
When I deactivate and remove
|
The I'm now contemplating trying a different approach, i.e. redoing the API that all of these modules use, such that their handlers are automatically merged/stacked, like I have been doing to Would this solve this current issue, with |
…, such that inheriting existing handlers is the default behavior.
…, such that inheriting existing handlers is the default behavior.
…, such that inheriting existing handlers is the default behavior.
…, such that inheriting existing handlers is the default behavior.
…, such that inheriting existing handlers is the default behavior.
…, such that inheriting existing handlers is the default behavior.
#1789 implements the refactoring of the FSIO API, so that modules like I'll now start on the second part, which is getting |
…, such that inheriting existing handlers is the default behavior. (#1789)
…unction, for resolving paths. Most of the time, this will be a pass-through. However, modules like mod_vroot play games with filesystem paths, and other modules need a way to play by those same rules.
#1790 adds a new FSIO API, for resolving paths. Right now, only The last part will be updating the |
…unction, for resolving paths. Most of the time, this will be a pass-through. However, modules like mod_vroot play games with filesystem paths, and other modules need a way to play by those same rules.
…unction, for resolving paths. (#1790) Most of the time, this will be a pass-through. However, modules like mod_vroot play games with filesystem paths, and other modules need a way to play by those same rules.
Here's the last PR, for Using that, and then running your |
Hi @Castaglia,
Unfortunately, all files get still filtered out, even those to which the user has access to. The log looks promising, but there still seems to be something that does not consider the new way of looking up files:
|
|
…hecking POSIX ACLs until after all uses.
…hecking POSIX ACLs until after all uses. (#1791)
Thanks! There's some garbled characters in these log messages, which should now be fixed via #1791. If you try this again, and see it happen again like the above, you should also see something like:
or:
The difference being whether this is Update: Ah, for the later provided logs, it looks to be the "access()" callback. Perfect. |
It is working 😃. Now, the files to which the user has no access are filtered out and the other remain visible. This is the trace log of fsio:
In the home directory of
When I remove the read permission for everyone and change it e.g. to
Thank you very much for your efforts! |
… Issue #1780 in the `statvfs(2)` system calls in mod_sftp.
What I Did
I tried to activate the option
HideNoAccess
to make sure that the user gets only files and directory listings to which he has access to. I have used the following configuration snippet in my vHost:Unfortunately, the directory listing is empty.
The issue is related to
mod_vroot
. The paths to the directories inside the user's home directory are regarded as absolute paths. Let us assume the following case: The user gets chrooted to his home directory under/srv/ftp/testuser
. His home directory contains the following directories:When the user
testuser
logs in, his home directory is empty:The trace gives the answer, because the directory permissions are looked up e.g. for the directory
/abc
(does not exist) and not for/srv/ftp/testuser/abc
. Please have a close look at the following trace excerpt. Bothfacl
andsftp
complain about not existing directories;I have created the directory
/abc
:and now the directory
abc
is listed in the user's home directory:What I Expected/Wanted
All directories to which the user has access to are listed and the other one get filtered out.
ProFTPD Version and Configuration
Is it possible to fix the issue?
Thank you very much.
The text was updated successfully, but these errors were encountered: