ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
69303
|
Thu Feb 18 19:21:57 2021 |
| Jacky Li | zli@hawaii.edu | Question | Linux | 3.1.4 | export/archive a logbook | 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 |
69304
|
Fri Feb 19 08:35:53 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.4 | Re: export/archive a logbook | 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
|
|
69305
|
Fri Feb 19 09:59:04 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.4 | Re: Path disclosure on unfound file | 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).
|
|
|
|
69306
|
Fri Feb 19 19:48:11 2021 |
| Gabriel Lopez | gabelopez@bnl.gov | Bug report | Linux | 3.1.4 | Re: Path disclosure on unfound file | 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).
|
|
|
|
|
69369
|
Mon Jun 14 16:15:10 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | Linux | Windows | Mac OSX | All | Other | 3.1.4 | Additional forbidden attributes | Hello Stefan,
I stubbled on a issue with our elog.
We introduced an attribute "mode" to one of the elogs and it breaks the "Find" function as this attribute is already used for the viewing settings "full", "summary" and "threaded".
(HTTP parameter pollution)
I suspect other special attributes used by the internals of elog should also not be allowed.
A quick search in the "Find" reveals these attributes in the URL, so I guess, these should also be avoided.
This list could be incomplete
npp, ma, da, ya, mb, db, yb, attach, reverse, mode
A simple workaround would be updating the documentation to add these to the list of forbidden attributes.
https://elog.psi.ch/elog/config.html
Maybe a warning can be added, if the elog behaves unexpected, try other attribute names, as they can conflict with internal attributes.
A fix could be to add a prefix for internal attributes, which can't be used for user attributes.
Best wishes,
Sebastian
PS: I also noticed using the "Find" command, the generated URL contains 2 reverse attributes like "reverse=0&reverse=1" |
69385
|
Mon Jul 19 18:41:29 2021 |
| Janusz Szuba | janusz.szuba@xfel.eu | Question | Linux | 3.1.4 | Deny option and Guest commands | Hi,
I have a logbook with guest access and guest can also enter a new entry (in config: Guest List Menu commands = New, Find, Select, Login). For other reason in a global section, I put
Deny New = account1, account2
This somehow invalidates Guest List Menu commands, since as guest I don't see New button anymore. Is this behaviour desired? Otherwise, I would need to move Deny option to plenty of individual logbook configs. Just to explain the reason, those accounts are set up to only read entries and not to create new ones. Or maybe you can suggest a different solution?
Best |
69386
|
Wed Jul 21 16:16:29 2021 |
| Alan Grant | agrant@winnipeg.ca | Question | Windows | 3.1.4 | Logging Main page entries, each with multiple ongoing events | Is there any way to log child events on the detail pages for a fixed number of entries on the main page? For example, I have 15 vehicles to enter on the main page, ID'd by Vehicle Number. Within each of those entries I will be logging ongoing repair service entries with certain attributes.
So how might I design this concept without having repeating vehicle entries on the main page for every service event, and preferably without splitting the information between two linked logbook tabs?
|
69389
|
Mon Aug 30 03:08:15 2021 |
| Alan Grant | agrant@winnipeg.ca | Question | Windows | 3.1.4 | Large log file size | Can the size of the application log file affect performance? |
|