Skip to content
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

allowLinking does not work #6573

Open
tronicek opened this issue Feb 24, 2024 · 9 comments
Open

allowLinking does not work #6573

tronicek opened this issue Feb 24, 2024 · 9 comments
Assignees
Labels
Status: Accepted Confirmed defect or accepted improvement to implement, issue has been escalated to Platform Dev Type: Bug Label issue as a bug defect

Comments

@tronicek
Copy link

Brief Summary

The application does not follow symbolic links when a property allowLinking in the virtual server is set to true.

Expected Outcome

Payara is expected to follow symbolic links in the application folder. It works in Eclipse Glassfish.

Current Outcome

Payara does not follow symbolic links in the application folder.

Reproducer

  1. Deploy a web application.
  2. Create a symbolic link in payara6/glassfish/domains/domain1/application/yourappv1. For example, cd payara6/glassfish/domains/domain1/application/yourappv1; ln -s ~/pdf.
  3. In admin console, add property allowLinking in server-config -> Virtual Servers -> server and set its value to true.
  4. Access files in the pdf folder, such as https://www.yourname.cz/yourapp/pdf/1.pdf.

Operating System

Amazon Linux

JDK Version

OpenJDK Runtime Environment Corretto-17.0.10.8.1

Payara Distribution

Payara Server Full Profile

@tronicek tronicek added Status: Open Issue has been triaged by the front-line engineers and is being worked on verification Type: Bug Label issue as a bug defect labels Feb 24, 2024
@felixif
Copy link

felixif commented Feb 26, 2024

Hello @tronicek,

I have tested the symbolic links, with the only difference being that I created the symbolic link this way: ln -s ~/Documents/payara-6.2024.2/payara6/glassfish/domains/domain1/application/ci6357-0.1-SNAPSHOT/pdf ~/pdf, followed by mkdir ~/Documents/payara-6.2024.2/payara6/glassfish/domains/domain1/application/ci6357-0.1-SNAPSHOT/pdf. Then I dropped one of our guides in the pdf folder, and I can access it via Payara Server with no issue on the /<appname>/pdf/1.pdf url

Your command created a symbolic link from the pdf folder inside "yourappname" pointing towards the home pdf folder, while my command does the opposite. Using the readlink CLI utility on the pdf folder inside "yourappname", my method prints home/felix/Documents/payara-6.2024.2/payara6/glassfish/domains/domain1/application/ci6357-0.1-SNAPSHOT/pdf/1.pdf, while your method prints /home/felix/pdf . I am not entirely sure if this is a bug or expected behaviour, so I will bring this issue up with my teammates. Meanwhile, the above method should work just fine. Please let me know if you managed to get the symbolic links working.

Best regards,
Felix Ifrim

@felixif felixif added Status: Pending Waiting on the issue requester to give more details or share a reproducer and removed Status: Open Issue has been triaged by the front-line engineers and is being worked on verification labels Feb 26, 2024
@tronicek
Copy link
Author

tronicek commented Feb 27, 2024

Hi @felixif,

ln -s ~/Documents/payara-6.2024.2/payara6/glassfish/domains/domain1/application/ci6357-0.1-SNAPSHOT/pdf ~/pdf
creates a link ~/pdf that points to ~/Documents/payara.../pdf. When you drop a file in ~/pdf, the file is created in ~/Documents/payara.../pdf, which is under your application root. You can check it simply by inspecting that folder.
When you access that file, no symbolic link is followed and it is no surprise that it works.

To prevent misunderstanding, let me describe once more what I expect from allowLinking:
I created a link in the application root (payara6/glassfish/domains/domain1/application/yourappv1) that pointed to a folder out of the application root and expected Payara to follow the link. It works under Glassfish but not under Payara.
The link you create is always the same regardless of what command you use to create it because it is simply a file that contains the absolute path to the destination folder.

Copy link

github-actions bot commented Mar 4, 2024

Greetings,
It's been more than 5 days since we requested more information or an update from you on the details of this issue. Could you provide an update soon, please?
We're afraid that if we do not receive an update, we'll have to close this issue due to inactivity.

@github-actions github-actions bot added Status: Abandoned User has not supplied reproducers for bug report, soon to be closed if user doesn’t come back and removed Type: Bug Label issue as a bug defect Status: Pending Waiting on the issue requester to give more details or share a reproducer labels Mar 4, 2024
@tronicek
Copy link
Author

tronicek commented Mar 4, 2024 via email

@aubi
Copy link
Contributor

aubi commented Mar 8, 2024

The allowLinking is still described in our documentation, so it should work.
I tried it with clusterjsp as a reproducer and it really doesn't work. Using latest Payara 6.2024.2.

I tried link both directory and a file:

glassfish/domains/domain1/applications/clusterjsp$ ln -s /home/aubi/tmp
glassfish/domains/domain1/applications/clusterjsp$ ln -s /home/aubi/tmp/x.png

I set the allowLinking to true as described, in server-config -> Virtual Servers -> server, Additional Properties

No request succeeded, all return 404:

http://localhost:8080/clusterjsp/x.png
HTTP Status 404 - Not Found
http://localhost:8080/clusterjsp/tmp/x.png
HTTP Status 404 - Not Found

Note for myself: Something wrong with allowLinking in FileDirContext.validate()

@felixif Can we remove the Status: Abandoned? It's obviously wrong. Thanks.

Copy link

Greetings,
It's been more than 5 days since this issue was identified as abandoned.
We have closed this issue due to inactivity, please feel free to re-open it if you have more information to share.

@github-actions github-actions bot removed the Status: Abandoned User has not supplied reproducers for bug report, soon to be closed if user doesn’t come back label Mar 14, 2024
@tronicek
Copy link
Author

Are you serious?

@felixif felixif added the Status: Accepted Confirmed defect or accepted improvement to implement, issue has been escalated to Platform Dev label Mar 14, 2024
@felixif
Copy link

felixif commented Mar 14, 2024

Hello @tronicek,

Apologies for the issue being mislabeled as Abandoned and also for waiting so long for my answer. Me and Petr had a conversation where he explained my mistake in understanding symbolic links. I was able to reproduce the problem with no issues, so I will mark it as accepted. The issue has been raised to our Engineering team, codename FISH-8399.

Thank you very much for your report, and I apologise for the delay and the lack of understanding on my part.

Best regards,
Felix

@felixif felixif reopened this Mar 14, 2024
@felixif felixif added the Type: Bug Label issue as a bug defect label Mar 14, 2024
@tronicek
Copy link
Author

Hi @felixif,

No problem. I am happy you are going to fix it because I really use this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Accepted Confirmed defect or accepted improvement to implement, issue has been escalated to Platform Dev Type: Bug Label issue as a bug defect
Projects
None yet
Development

No branches or pull requests

3 participants