Last default time bug, posted by Sebastian Schenk on Mon Mar 1 16:02:02 2021
|
Hello all,
I have the issue, that we can't list entries older than 1 year, if "Last default = 31" (or any other number, but they are restricted to 1, 3, 7, 31, 92, 182, 364) is active.
The quick filter displays the option for "-- all entries --" but selecting this only reloads the default time frame (31 days).
A workaroud is to select a different time e.g. 1 day and then modifying the URL to ?last=1000 or so, gives acces to the old entries.
But this is not the intended way to do it.
The Find results are also affected by this. e.g. selecting 1.1.2020 to 1.6.2020 with "Last default = 31" yields 0 results.
The "Show last default" atrtribute for 1, 3, 7, 31, 92, 182, 364 work fine and overwrite the "last default" time in the quick filter.
In the Find page, there will be a "All entries" option at the top of the date selection box, if "Show last default" equals to 1, 3, 7, 31, 92, 182 or 364
(2, Bug: it is empty for "Show last default = 0" and not All entries")
Selecting "All entries" or the empty first value in the Find "show last:" date , will give a Find result with the "Last default" time constraint.
Thus it is not possible to get any entry older then the longst period possible (364 days), if you don't know about the workaround.
Best wishes,
Sebastian
PS: I use a self-compiled version of elog up to the 395e101 commit in the bitbucket repository with pull request #7 (which hasn't been merged for over 1,5 years) and a simple patch for our local LDAP. |
Path disclosure on unfound file, posted by Bruce Bush on Wed May 6 17:35:14 2015
|
Greetings,
Running elog 3.1.0 on CentOS 6.6. When I try to access a nonexistent file, elog reveals a path in the 404 page. For example:
Not Found
The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server
ELOG version 3.1.0
Is there any way to use a custom 404 page with elog, or to make it stop displaying the file information?
Thank you,
bb
|
Re: Path disclosure on unfound file, posted by Stefan Ritt on Wed Jun 10 09:12:06 2015 
|
What URL did you use? If I try here on this forum I get:
which looks fine to me.
| Bruce Bush wrote: |
|
Greetings,
Running elog 3.1.0 on CentOS 6.6. When I try to access a nonexistent file, elog reveals a path in the 404 page. For example:
Not Found
The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server
ELOG version 3.1.0
Is there any way to use a custom 404 page with elog, or to make it stop displaying the file information?
Thank you,
bb
|
|
|
Re: Path disclosure on unfound file, posted by Travis Unkel on Fri Aug 18 01:02:41 2017
|
I am having the same issue. If you go to midas.psi.ch/elogs/12345.htm you get the path disclosure issue.
| Stefan Ritt wrote: |
|
What URL did you use? If I try here on this forum I get:
which looks fine to me.
| Bruce Bush wrote: |
|
Greetings,
Running elog 3.1.0 on CentOS 6.6. When I try to access a nonexistent file, elog reveals a path in the 404 page. For example:
Not Found
The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server
ELOG version 3.1.0
Is there any way to use a custom 404 page with elog, or to make it stop displaying the file information?
Thank you,
bb
|
|
|
|
Re: Path disclosure on unfound file, posted by prinnydood on Thu Dec 31 18:35:19 2020
|
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). |
|
Re: Path disclosure on unfound file, posted by Stefan Ritt on Fri Jan 8 13:47:14 2021
|
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).
|
|
|
Re: Path disclosure on unfound file, posted by Gabriel Lopez on Wed Feb 3 17:28:16 2021
|
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).
|
|
|
|
Re: Path disclosure on unfound file, posted by Stefan Ritt on Fri Feb 19 09:59:04 2021
|
I made a new RPM: https://elog.psi.ch/elog/download/RPMS/elog-3.1.4-3.el7.x86_64.rpm
| Gabriel Lopez wrote: |
|
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).
|
|
|
|
|
Re: Path disclosure on unfound file, posted by Gabriel Lopez on Fri Feb 19 19:48:11 2021
|
Thank you for your work. Works like a charm!
| Stefan Ritt wrote: |
|
I made a new RPM: https://elog.psi.ch/elog/download/RPMS/elog-3.1.4-3.el7.x86_64.rpm
| Gabriel Lopez wrote: |
|
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).
|
|
|
|
|
|
export/archive a logbook, posted by Jacky Li on Thu Feb 18 19:21:57 2021
|
Hi,
I have an elogd server serves many logbooks. May I know what is a good way to export or achive one its logbooks? Thank you.
Jacky |
|
Re: export/archive a logbook, posted by Stefan Ritt on Fri Feb 19 08:35:53 2021
|
Find -> Export to: CSV (or any other format) -> Search
| Jacky Li wrote: |
|
Hi,
I have an elogd server serves many logbooks. May I know what is a good way to export or achive one its logbooks? Thank you.
Jacky
|
|
|
elog server go to high CPU and hangs, posted by Stefano Lacaprara on Thu Feb 18 09:14:28 2021
|
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 |
|
Re: elog server go to high CPU and hangs, posted by David Pilgram on Thu Feb 18 12:05:52 2021
|
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 |
|
Re: elog server go to high CPU and hangs, posted by Stefan Ritt on Thu Feb 18 12:06:12 2021
|
Usually a restart of the elogd server helps. If the problem persists, one of the logbooks might be corrupt. Try to disable one logbook at a time to figure out which one it is. Then
remove that one and set it up freshly.
Stefan |
|
Different Top Groups or Groups have the same logbook name , posted by MATT TERRON on Tue Feb 2 04:01:21 2021
|
I have built different top groups for different departments. But occasionally these different top groups have the same logbook name, say 'Maintenance Log'. So is there a way I can have the same logbook name under different 'Top Groups', rather than rename these logbooks as 'Department1 Maintenance Log' all the way to 'Department_X Maintenance Log'? |
|
Re: Different Top Groups or Groups have the same logbook name , posted by Stefan Ritt on Tue Feb 2 07:43:49 2021
|
Unfortunately you have to name these top groups differently, because they are internally used for the database name.
| MATT TERRON wrote: |
|
I have built different top groups for different departments. But occasionally these different top groups have the same logbook name, say 'Maintenance Log'. So is there a way I can have the same logbook name under different 'Top Groups', rather than rename these logbooks as 'Department1 Maintenance Log' all the way to 'Department_X Maintenance Log'?
|
|
|
Re: Different Top Groups or Groups have the same logbook name , posted by MATT TERRON on Tue Feb 2 08:17:15 2021
|
So both Top Group names and Logbook names should be unique inside one .cfg file, is that correct?
| Stefan Ritt wrote: |
|
Unfortunately you have to name these top groups differently, because they are internally used for the database name.
| MATT TERRON wrote: |
|
I have built different top groups for different departments. But occasionally these different top groups have the same logbook name, say 'Maintenance Log'. So is there a way I can have the same logbook name under different 'Top Groups', rather than rename these logbooks as 'Department1 Maintenance Log' all the way to 'Department_X Maintenance Log'?
|
|
|
|
Re: Different Top Groups or Groups have the same logbook name , posted by Stefan Ritt on Tue Feb 2 08:25:46 2021
|
That's correct.
| Stefan Ritt wrote: |
|
Unfortunately you have to name these top groups differently, because they are internally used for the database name.
| MATT TERRON wrote: |
|
I have built different top groups for different departments. But occasionally these different top groups have the same logbook name, say 'Maintenance Log'. So is there a way I can have the same logbook name under different 'Top Groups', rather than rename these logbooks as 'Department1 Maintenance Log' all the way to 'Department_X Maintenance Log'?
|
|
|
|
elog slowness, posted by Giuseppe Cucinotta on Thu Jan 14 11:43:00 2021
|
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 |
|
Re: elog slowness, posted by Stefan Ritt on Thu Jan 14 14:05:19 2021
|
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
|
|
|
hidden files, posted by Lahreche Abdelmadjid on Sun Jan 10 11:13:31 2021
|
Hello;
Could I make change on program only on the " elogd.cfg" ?
Or is there onother files, because I think there is hidden files ? |
|
outdated debian package, posted by Chris Körner on Fri Dec 18 18:08:54 2020
|
Hi everyone,
I am currently trying to setup elog as a docker container. I wonder if there is any reason why the elog debian package is stuck at version 3.1.3? Would it be possible to update it to the latest version?
Thanks very much! |
|