| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69282
|
Tue Dec 15 17:41:57 2020 |
 | Satyajit Jena | satya.ino@gmail.com | Question | Linux | 3.1.4 | Re: Is there a way to upload a file in custom input? | Thanks Stefan,
I am not yet able to figure out how attachment submission is done, I am trying. It would be helpful if you can refer me to some pointer.
With regards,
satyajit
| Stefan Ritt wrote: |
|
When you submit a "normal" elog entry, you can click on "Choose file" to add an attachment. On a mobile device, you will then be asked to select a photo from your library or take one with your camera. You can do the same on a custom form. You have to extract the code from the normal submissoin form and program it on your custom page. It needs however some work and might not be straight forward.
Stefan
| Satyajit Jena wrote: |
|
Hi,
I am trying to implement a Custom input forms by following this https://elog.psi.ch/elogs/Contributions/49. Is there a way to also insert an image or files to it? I want to take a snap from the iPad and want that to go as an attachment or attach a file(s) into the form. Is there a way to do that?
Your suggestions are highly appreciated.
Regards,
sjena
|
|
|
|
69285
|
Thu Dec 31 18:35:19 2020 |
| prinnydood | moltensolderlabs@pm.me | Bug report | Linux | 3.1.3 | Re: Path disclosure on unfound file | I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point). |
| Attachment 1: no_extension.png
|
|
| Attachment 2: nonexistent_html.png
|
|
| Attachment 3: random_extension.png
|
|
| Attachment 4: valid_html_file_with_html_extension.png
|
|
|
69288
|
Fri Jan 8 13:47:14 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.3 | Re: Path disclosure on unfound file | Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a
| prinnydood wrote: |
|
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).
|
|
|
69293
|
Thu Jan 14 11:43:00 2021 |
 | Giuseppe Cucinotta | giuseppe.cucinotta@unifi.it | Question | Linux | 3.1.3 | elog slowness | We run elog on a server to provide a logbook for our laboratory. We noticed that elog is very slow on loading pages: browser pages spend a lot of time in charging (actually one can speed the procedure refreshing the page but it is quite annoying).
I checked the server load with top and it doesn't show any abnormal CPU or memory usage. Then I ran lsof and I noticed that there are more than 200 entries related to the same elog PID and labelled with CLOSE_WAIT.
My questions are: can the slowness of my logbook be due to the presence of all these CLOSE_WAIT entries (which seems if I understood well wait for a response)? If it's the case, how can I solve this issue?
Thanks |
|
69294
|
Thu Jan 14 14:05:19 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.3 | Re: elog slowness | Have you tried to restart the elogd server? The CLOSE_WAIT could be dangling network connections, which were not properly closed by the browser.
| Giuseppe Cucinotta wrote: |
|
We run elog on a server to provide a logbook for our laboratory. We noticed that elog is very slow on loading pages: browser pages spend a lot of time in charging (actually one can speed the procedure refreshing the page but it is quite annoying).
I checked the server load with top and it doesn't show any abnormal CPU or memory usage. Then I ran lsof and I noticed that there are more than 200 entries related to the same elog PID and labelled with CLOSE_WAIT.
My questions are: can the slowness of my logbook be due to the presence of all these CLOSE_WAIT entries (which seems if I understood well wait for a response)? If it's the case, how can I solve this issue?
Thanks
|
|
|
69299
|
Wed Feb 3 17:28:16 2021 |
| Gabriel Lopez | gabelopez@bnl.gov | Bug report | Linux | 3.1.4 | Re: Path disclosure on unfound file | Hello, This is coming up as a high vulnerability in our scans. Are there plans to update the rpm for this fix? If so is there an ETA? Any update would be much appreciated. Currently running elog-3.1.4-2
| Stefan Ritt wrote: |
|
Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a
| prinnydood wrote: |
|
I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.
The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.
This is what I found:
1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish
2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd
3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path
4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.
Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).
=====
My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.
====
What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.
(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).
|
|
|
|
69300
|
Thu Feb 18 09:14:28 2021 |
| Stefano Lacaprara | stefano.lacaprara@pd.infn.it | Bug report | Linux | 3.1.4-2 | elog server go to high CPU and hangs | Dear expert,
I'm running the latest git version of elog ELOG V3.1.4-395e101a on ubuntu 20.04.2.
I'm experiencing frequent hangs of the elog server: the status is always reported as running, but the web server is not responding.
The only hint I have of something strange is that the elogd process is using a lot of CPU (50-100%), the log do not show anything suspect
as far as I can see.
Has anyone experienced something similar or has any idea how can I start to debug the problem?
Sorry for lack of many information, but I don't know what to look at.
Thanks in advance
Stefano |
|
69301
|
Thu Feb 18 12:05:52 2021 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 3.1.4-2 | Re: elog server go to high CPU and hangs | Dear Stefano,
Try the entry I wrote some time ago elog:68655
David.
> Dear expert,
> I'm running the latest git version of elog ELOG V3.1.4-395e101a on ubuntu 20.04.2.
> I'm experiencing frequent hangs of the elog server: the status is always reported as running, but the web server is not responding.
> The only hint I have of something strange is that the elogd process is using a lot of CPU (50-100%), the log do not show anything suspect
> as far as I can see.
>
> Has anyone experienced something similar or has any idea how can I start to debug the problem?
>
> Sorry for lack of many information, but I don't know what to look at.
>
> Thanks in advance
> Stefano |
|