Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 70 of 806  Not logged in ELOG logo
ID Datedown Icon Author Author Email Category OS ELOG Version Subject
  69309   Tue Feb 23 17:20:39 2021 Reply Andreas Luedekeandreas.luedeke@psi.chQuestionLinuxV3.1.4-80633baRe: Date conversion

If you define a field as "datetime" then you'll get the standard ELOG input field for datetime. It will be stored as seconds of the epoch (seconds since 1.1.1970).

You can define a field as a default string input, then it is stored as a string. But you can convert that string by a shell scripts into seconds of the epoch. See "subst" command in the documentation of the elog syntax:

Subst <attribute> = <string>
When submitting logbook entries, attribute values can be substituted by some text. This text can contain arbitrary fixed text and following values:
  • $<attribute>: The entered value of the attribute itself
  • $host: The host name where elogd is running
  • $remote_host: The host name of the host from with the entry was submitted
  • $short_name: The login name (if password file is present)
  • $long_name: The full name from the password file for the current user
  • $user_email: The email address from the password file for the current user
  • $logbook: The name of the current logbook
  • $date: The current date, formatted via "Date format"
  • $utcdate: The current UTC date (GMT) and time, formatted via "Date format"
  • $version: The version of the ELOG server in the form x.y.z
  • $revision: The Subversion reversion of the ELOG server as an integer number
  • $shell(<command>): <command> gets passed to the operating system shell and the result is taken for substitution.

Following example use this feature to add the remote host name to the author:
Subst Author = $author from $remote_host

Following example substitutes an attribute with the contents of a file:
  Subst Info = $shell(cat /tmp/filename)              (Unix)
  Subst Info = $shell(type c:\tmp\filename)           (Windows)

A special option are automatically generated tags, which are automatically incremented for each new message. This is achieved by putting #'s into the substitution string, which is used as a placeholder for the incrementing index. Each "#" stands for one digit, thus the statement
Subst Number = XYZ-#####
results in automatically created attributes "Number" of the form
XYZ-00001
XYZ-00002
XYZ-00003
and so on. In addition to the #'s one may specify format specifiers which are passed to the strftime function. This allows to create tags wich contain the current year, month and so on. Once the date part of the attribute changes, the index restarts from one. The statement
Subst Number = XYZ-%Y-%b-###
results in automatically created attributes "Number" of the form
XYZ-2005-Oct-001
XYZ-2005-Oct-002
XYZ-2005-Oct-003

and
XYZ-2005-Nov-001
XYZ-2005-Nov-002

on the next month.
Martin Neumann wrote:

Hi,

I am trying to figure out how ELOG works and I have a problem.

I have one datetime attribute, where I want the user to be able to enter the time in ISO8601 format (YYYY-MM-DD HH:MM) instead of the buttons.

How do I manage that this input is converted correctly into the internal format?

I tried adding a hidden locked Attribute called IntDate and use "Subst IntDate = $start" but the result is dates in 1970, even though I have set the Time Format to "%F %H:%M"

 

  69308   Tue Feb 23 12:12:14 2021 Question Martin Neumannelog.20.beazy@spamgourmet.comQuestionLinuxV3.1.4-80633baDate conversion

Hi,

I am trying to figure out how ELOG works and I have a problem.

I have one datetime attribute, where I want the user to be able to enter the time in ISO8601 format (YYYY-MM-DD HH:MM) instead of the buttons.

How do I manage that this input is converted correctly into the internal format?

I tried adding a hidden locked Attribute called IntDate and use "Subst IntDate = $start" but the result is dates in 1970, even though I have set the Time Format to "%F %H:%M"

  69307   Mon Feb 22 12:29:16 2021 Question Stefano Lacaprarastefano.lacaprara@pd.infn.itQuestionLinuxELOG V3.1.3-Problem in logging with LDAP and passwd
Dear experts,
   I have a logbook which has authentication as follow

Authentication = LDAP, File
Password file = PASSWD.file
LDAP server = ldaps://it-ldap-XXX.XXX.XX:1636
LDAP userbase = ou=people,ou=RGY,o=XXX,c=XX
LDAP login attribute = uid
LDAP register = 0
Self register = 0
Allow password change = 0

Some of the my user (but not all) have issue in accessing this protected elogbook.
The ldap password is correct (we checked).
What I see in the log is as follow:

22-Feb-2021 11:25:51 [XXX.YYY.ZZZ.QQ] {Beam Run} LOGIN user "USERNAME" (attempt)
22-Feb-2021 11:25:59 [XXX.YYY.ZZZ.QQ] {Beam Run} LOGIN user "USERNAME" (attempt)

The user USERNAME is present in PASSWD.file.

For other user, for which the login works, I do see an (attempt) and then (success)

we tried the standard stuff: clear cache/cookies and with different browser. We also tried to remove the user from PASSWD.file and 
create it again, but nothing has worked.

Any suggestion how I can debug this problem?

Thanks in advance,
  Stefano
  69306   Fri Feb 19 19:48:11 2021 Reply Gabriel Lopezgabelopez@bnl.govBug reportLinux3.1.4Re: 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).

 

 

 

 

  69305   Fri Feb 19 09:59:04 2021 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux3.1.4Re: 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).

 

 

 

  69304   Fri Feb 19 08:35:53 2021 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.1.4Re: 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

 

  69303   Thu Feb 18 19:21:57 2021 Question Jacky Lizli@hawaii.eduQuestionLinux3.1.4export/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

  69302   Thu Feb 18 12:06:12 2021 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux3.1.4-2Re: elog server go to high CPU and hangs
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
ELOG V3.1.5-3fb85fa6