Build-time detection of Linux POSIX ACL support broken since 1.3.8rc2 #1568
Comments
|
Can you provide the server-side debug logging generated? See e.g. http://www.proftpd.org/docs/howto/Debugging.html That might help provide some more clues about what's happening on the backend. |
|
All right, here goes, I have created debug logs for
Something that stands out is that Edit: I have fiddled around with
So it smells as if ProFTPD fails to correctly assess the users' access rights to file system objects. Log of
|
|
Hmm. There have been almost no changes to Thanks! |
|
For what it's worth, this also results in the "Permission denied" error for the client. |
|
Just confirm (for my local setup) -- do the textual user, group names retrieved align with the user/group names displayed by I understand wanting to keep the actual IDs, names obscured. I just need to know whether the "retrieved group names", logged by ProFTPD, include any of e.g.: If not, that might explain one possible cause of the behavior you see. I don't think that will be the case, but I need to double-check. |
|
I'm able to reproduce this locally now; hopefully it won't be long before I have a fix. |
|
In my local setup, I added some additional trace logging using: Using ProFTPD 1.3.7e, where the (I am using That says that ProFTPD is using the "facl" When using ProFTPD 1.3.8, I see something different: Why is ProFTPD using the default "system" |
|
I have narrowed this down to changes between ProFTPD 1.3.8rc1 (which does not exhibit this behavior), and 1.3.8rc2. Now to narrow things down further. |
|
Ah-hah! I tracked down the offending commit: 7a79e76 And the PR that that commit references: https://github.com/proftpd/proftpd/pull/1203/files At first glance, these commits do not seem like they're related to POSIX ACL capabilities, filesystem APIs, or the The commits in question are related to the flags used when linking the ProFTPD executable. They are also used by the Autoconf-generated For example, for the working build, here's what we see in the generated We see that And for the buggy, broken build? Here, on the generated This In addition, we can see the change in the and for the buggy build: Notice that the ACL library linker flag ( And because these Given the nature of the cause, it's possible that more than just the POSIX ACL tests, in the |
Castaglia
changed the title
|
Now that was a wild ride. Linker problems, who would have thought. I assume your question about the user/group names in the log are now moot, anyhow I kept the originals and it was the correct user logins / group names without the At any rate thank you for all the amazing work you put into this application. |
Castaglia
added a commit
that referenced
this issue
Jan 31, 2023
…g the manipulation of the `LDFLAGS` environment variable for use in these tests.
Castaglia
changed the title
Castaglia
added a commit
that referenced
this issue
Jan 31, 2023
…g the manipulation of the `LDFLAGS` environment variable for use in these tests.
Castaglia
added a commit
that referenced
this issue
Jan 31, 2023
…g the manipulation of the `LDFLAGS` environment variable for use in these tests.
Castaglia
added a commit
that referenced
this issue
Jan 31, 2023
Issue #1568: Fix the Autoconf tests for Linux POSIX ACLs by correctin…
Castaglia
added a commit
that referenced
this issue
Jan 31, 2023
|
This has been fixed in the master branch, and backported to the 1.3.8 branch now. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What I Did
Upgraded from
1.3.7eto1.3.8.System is Arch Linux, package is the proftpd AUR package.
What I Expected/Wanted
Basically, version
1.3.8working comparably well as version1.3.7e.Instead the server is unusable because while the users can successfully connect, they cannot view the shared directory's contents.
Downgrading to version
1.3.7eworks around the issue.ProFTPD Version and Configuration
Version is
1.3.8. I built and tested this version twice, both built with yay using the "clean" feature, i.e. without having files of previous builds lying around.Something of note concerning the configuration, I am using Access Control Lists (ACL) to control which user may access what on the FTP server, and due to this I am making use of the
mod_facl.cmodule.As far as FTP servers go this may be somewhat unusual, which is why I suspect a regression in
mod_facl.c.Output of
proftpd -VConfiguration file
FileZilla FTP client message log of version 1.3.8 (bad)
FileZilla FTP client message log of version 1.3.7e (good)
The text was updated successfully, but these errors were encountered: