Dear all, 

I have a question for you. On my elog server I have plenty of images not included in any logbook entry, but that nevertheless I would the user to have access to that via the browser. In order words, I would like to have a link like this https://myelog/my_pics_folder/my_pic.png

I have realized that if I put my_pics_folder in the script folder, then it works as I wanted, but I strongly doubt this is the right position. If I put in the resources folder, it is not found and the elogd displays a message saying that my_pics_folder is not a valid logbook.

Do you have any suggestions for this problem? 

Thanks in advance and enjoy your day!

toto

Hi, I have been using elog for years at CERN.

Now I installed in my local workstation at my home inistitue

and sysadmin reported the following vulnerabilities:

  - Configuration File Disclosure (CVE-2019-3992)

  - Password Hash Disclosure (CVE-2019-3993)

  - Use After Free (CVE-2019-3994)

  - NULL Pointer Dereference (CVE-2019-3995)

  - Unintended Proxy (CVE-2019-3996)

Am I doing soimething wrong?

sysadmin will not allow me to use it until it is fixed....

Any help is welcome.

The CVEs you refer to are very old and have been fixed a long time ago.

Please refer to:
https://www.tenable.com/security/research/tra-2019-53

This report states that all the reported problems are fixed as of ELOG 3.1.4-283534d or later.

Note that the elog git history does not refer to these CVEs because
they were fixed before the CVE number was assigned, per "Disclosure Timeline"
in the above document. The relevant commits are listed under "Additional References".

K.O.

Ok, many many thanks!
I will pass the info to my sysadmin.
Best Regards.

> The CVEs you refer to are very old and have been fixed a long time ago.
> 
> Please refer to:
> https://www.tenable.com/security/research/tra-2019-53
> 
> This report states that all the reported problems are fixed as of ELOG 3.1.4-283534d or later.
> 
> Note that the elog git history does not refer to these CVEs because
> they were fixed before the CVE number was assigned, per "Disclosure Timeline"
> in the above document. The relevant commits are listed under "Additional References".
> 
> K.O.

> Ok, many many thanks!
> I will pass the info to my sysadmin.
> Best Regards.
> 
> > The CVEs you refer to are very old and have been fixed a long time ago.
> > 
> > Please refer to:
> > https://www.tenable.com/security/research/tra-2019-53
> > 
> > This report states that all the reported problems are fixed as of ELOG 3.1.4-283534d or later.
> > 
> > Note that the elog git history does not refer to these CVEs because
> > they were fixed before the CVE number was assigned, per "Disclosure Timeline"
> > in the above document. The relevant commits are listed under "Additional References".
> > 
> > K.O.

Am I wrong that the windows executable version on the site is dated 2018? 3.1.4-2?

> > > The CVEs you refer to are very old and have been fixed a long time ago.
> 
> Am I wrong that the windows executable version on the site is dated 2018? 3.1.4-2?

I confirm. Windows executables at https://elog.psi.ch/elog/download/windows/
and Debian packages at https://packages.debian.org/search?keywords=elog all
appear to be older than the cve fixes.

I trust Stefan is reading this thread and will do something about it. My vote would
be to remove the download link to the windows executables and ask Debian to remove
the elog package. I think they have a way for upstream developers (Stefan) to request
removal of unmaintained out-of-date insecure versions of their stuff. ROOT
was in the same situation years ago, the Debian package for ROOT was very old version,
also built incorrectly, and everybody complained to us that our stuff does
not work (midas, rootana, etc).

K.O.

> I trust Stefan is reading this thread and will do something about it. My vote would
> be to remove the download link to the windows executables and ask Debian to remove
> the elog package. I think they have a way for upstream developers (Stefan) to request
> removal of unmaintained out-of-date insecure versions of their stuff. ROOT
> was in the same situation years ago, the Debian package for ROOT was very old version,
> also built incorrectly, and everybody complained to us that our stuff does
> not work (midas, rootana, etc).

Yeah, I have to recompile the Windows version. Unfortunately my old Windows PC is gone, I
switched now completely to MacOSX and Linux. Probably have to borrow something from somewhere.
If anybody can compile the Windows version with the current source code I would be happy.

Stefan

> 
> Yeah, I have to recompile the Windows version. Unfortunately my old Windows PC is gone, I
> switched now completely to MacOSX and Linux. Probably have to borrow something from somewhere.
> If anybody can compile the Windows version with the current source code I would be happy.
> 
> Stefan

That would be most welcome!
I tried to recompile the windows version a while ago but didn't manage it.
I'm just a simple ELOG __user__ ^^
Looking forward to the new precompiled Windows version.

Thnx in advance!

daniel

> > I trust Stefan is reading this thread and will do something about it. My vote would
> > be to remove the download link to the windows executables and ask Debian to remove
> > the elog package. I think they have a way for upstream developers (Stefan) to request
> > removal of unmaintained out-of-date insecure versions of their stuff. ROOT
> > was in the same situation years ago, the Debian package for ROOT was very old version,
> > also built incorrectly, and everybody complained to us that our stuff does
> > not work (midas, rootana, etc).
> 
> Yeah, I have to recompile the Windows version. Unfortunately my old Windows PC is gone, I
> switched now completely to MacOSX and Linux. Probably have to borrow something from somewhere.
> If anybody can compile the Windows version with the current source code I would be happy.
> 
> Stefan

FWIW: you could cross-compile on Linux using 
   make CC=x86_64-w64-mingw32-gcc CFLAGS="-D_MSC_VER -DHAVE_VASPRintF -Imxml" LIBS="-Wl,--allow-multiple-definition -ladvapi32 -lwsock32 -lssl -lcrypto"
or so I thought... with build 3.1.4 - 395e101 I did manage, finally. 
However, with the latest git version everything seems to have been renamed to .cxx files (though it's still plain C ??!?!?) and my quick and dirty compile hack did not work. The binaries do work, I can start the server and access it via the web interface.

I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
Attached is a zip file with the binaries.
I was not able to create a new installer, these are just the executables

> I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> Attached is a zip file with the binaries.
> I was not able to create a new installer, these are just the executables

I tried to just exchange the attached binaries in my installation but this didn't worked.
elogd was not able to start.

Regards,

daniel

> > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > Attached is a zip file with the binaries.
> > I was not able to create a new installer, these are just the executables
> 
> I tried to just exchange the attached binaries in my installation but this didn't worked.
> elogd was not able to start.

hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....

> > > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > > Attached is a zip file with the binaries.
> > > I was not able to create a new installer, these are just the executables
> > 
> > I tried to just exchange the attached binaries in my installation but this didn't worked.
> > elogd was not able to start.
> 
> hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....

Error message is:

Error 1053: The service did not respond to the start or control request in a timely fashion.

I have to admit that I'm doing all this on a Server 2012 machine.

> > > > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > > > Attached is a zip file with the binaries.
> > > > I was not able to create a new installer, these are just the executables
> > > 
> > > I tried to just exchange the attached binaries in my installation but this didn't worked.
> > > elogd was not able to start.
> > 
> > hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....
> 
> Error message is:
> 
> Error 1053: The service did not respond to the start or control request in a timely fashion.
> 
> I have to admit that I'm doing all this on a Server 2012 machine.


Windows Server 2012 itself is almost EOL but it should still work, I believe.  I did see that the elog314-2.exe file is a Win32 binary whereas my binaries are 64bit. On Windows Server 2019 did not cause any issues.
Can you try the following
- extract the new elogd.exe binary somewhere , e.g. c:\temp\elogd.exe
- then type
  cd \Program Files (x86)\ELOG
  \temp\elogd.exe

- post the output/error code that you see.


  

> > I trust Stefan is reading this thread and will do something about it. My vote would
> > be to remove the download link to the windows executables and ask Debian to remove
> > the elog package. I think they have a way for upstream developers (Stefan) to request
> > removal of unmaintained out-of-date insecure versions of their stuff. ROOT
> > was in the same situation years ago, the Debian package for ROOT was very old version,
> > also built incorrectly, and everybody complained to us that our stuff does
> > not work (midas, rootana, etc).
> 
> Yeah, I have to recompile the Windows version. Unfortunately my old Windows PC is gone, I
> switched now completely to MacOSX and Linux. Probably have to borrow something from somewhere.
> If anybody can compile the Windows version with the current source code I would be happy.
> 
> Stefan

Hi Stefan,

I don't find any howto to build elog under windows, so i tried to compile elog-latest sources with cygwin (packages gcc + openssl-devel + openldap-devel + make). 
It builds, i could start elogd.exe and connect to localhost:8080 ! 
I generate a zip with cygwin dll needed to launch elogd and tools. I think they could be enclosed (maybe the cygwin licence file have to be added ?).

Btw it should be possible to crossbuild it under Mac or Linux. The problem is to test it ;-). On Mac, you can use UTM to create a Windows VM to do the work.

Bye
Laurent

> > I trust Stefan is reading this thread and will do something about it. My vote would
> > be to remove the download link to the windows executables and ask Debian to remove
> > the elog package. I think they have a way for upstream developers (Stefan) to request
> > removal of unmaintained out-of-date insecure versions of their stuff. ROOT
> > was in the same situation years ago, the Debian package for ROOT was very old version,
> > also built incorrectly, and everybody complained to us that our stuff does
> > not work (midas, rootana, etc).
> 
> Yeah, I have to recompile the Windows version. Unfortunately my old Windows PC is gone, I
> switched now completely to MacOSX and Linux. Probably have to borrow something from somewhere.
> If anybody can compile the Windows version with the current source code I would be happy.

it would be good if the current state was listed in https://elog.psi.ch/elogs/Vulnerabilities/ 
It seems there's now updated builds for at least windows, and the debian package still outdated?

Personally, I don't think removing download links and pulling packages should be more than a temporary measure.
Treating people fairly IMHO means they should be able to reach a safe version by the same means that brought and left them exposed.

A clear central source would be best, one that has 

- package autobuilds
- source
- cve list

If I understand correctly, currently only the source is up to date?


(I found py_elog on Github, so it could be an easy option to mirror ELOG there and let some free service handle the autobuilds.
I don't know how well one can flag vulnerabilities there, but likely it's possible, and ideally more people would help there.)


p.s.: My hat is off to the sysadmin who checked carefully, I wanted to introduce ELOG in a windows-centric place and I can't swear I would have checked this (official) download as well.

> it would be good if the current state was listed in https://elog.psi.ch/elogs/Vulnerabilities/
> It seems there's now updated builds for at least windows

I checked with Stefan and he plans to address both of those fairly soon.

> debian package still outdated?

We reached to the package maintainer (who is not us), if he cannot help,
we will request package removal through debian official channels. Then we have
to repeat same for the ubuntu package.

> A clear central source would be best ...

this already exists. git clone, make, run.

> p.s.: My hat is off to the sysadmin who checked carefully, I wanted to introduce ELOG in a windows-centric place and I can't swear I 
would have checked this (official) download as well.

I usually check the date of stuff I install and go "hmm..." if it is not super fresh or very fresh.

K.O.

> > debian package still outdated?
> We reached to the package maintainer

the good Roger Kalt requested removal of debian package elog
and it is now removed from debian-unstable. I am not sure
if it can be removed from debian-stable releases (debian-11, debian-10).

https://tracker.debian.org/pkg/elog
https://tracker.debian.org/news/1320035/removed-313-1-1-from-unstable/

K.O.

> > > debian package still outdated?
> removed from debian-unstable
> https://tracker.debian.org/pkg/elog
> https://tracker.debian.org/news/1320035/removed-313-1-1-from-unstable/

contacted security@debian.org and they requested removal from the next buster/bullseye point releases:

https://bugs.debian.org/1010196
https://bugs.debian.org/1010197

next is to request removal of ubuntu package.

K.O.

> > > > debian package still outdated?

the freebsd elog package was removed back in 2014 during
a purge of "not staged" packages. Originally submitted
in 2006, went through at least two maintainers.

https://www.freshports.org/www/elog/

K.O.

> next is to request removal of ubuntu package.

contacted ubuntu security team, got very quick response.

they noted our request and informed us that ubuntu cannot remove packages from existing releases.

https://bugs.launchpad.net/ubuntu/+source/elog/+bug/1970480

K.O.

 
> it would be good if the current state was listed in https://elog.psi.ch/elogs/Vulnerabilities/ 
> It seems there's now updated builds for at least windows, and the debian package still outdated?
> 
> Personally, I don't think removing download links and pulling packages should be more than a temporary measure.
> Treating people fairly IMHO means they should be able to reach a safe version by the same means that brought and left them exposed.
> 
> A clear central source would be best, one that has 
> 
> - package autobuilds
> - source
> - cve list
> 
> If I understand correctly, currently only the source is up to date?
> 
> 
> (I found py_elog on Github, so it could be an easy option to mirror ELOG there and let some free service handle the autobuilds.
> I don't know how well one can flag vulnerabilities there, but likely it's possible, and ideally more people would help there.)
> 
> 
> p.s.: My hat is off to the sysadmin who checked carefully, I wanted to introduce ELOG in a windows-centric place and I can't swear I would have checked this (official) download as well.

Very good ideas! Go ahead and implement them! We very much appreciate your contribution.

> The CVEs you refer to are very old and have been fixed a long time ago.
> 
> Please refer to:
> https://www.tenable.com/security/research/tra-2019-53
> 
> This report states that all the reported problems are fixed as of ELOG 3.1.4-283534d or later.
> 
> Note that the elog git history does not refer to these CVEs because
> they were fixed before the CVE number was assigned, per "Disclosure Timeline"
> in the above document. The relevant commits are listed under "Additional References".
> 
> K.O.

I should better capture these "additional references" and the "disclosure timeline"
before they vanish from tenable.com:
https://www.tenable.com/security/research/tra-2019-53

Additional References
https://bitbucket.org/ritt/elog/commits/7367647d40d9b43d529d952d3a063d53606697cb
https://bitbucket.org/ritt/elog/commits/38c08aceda8e5ac4bfdcc040710b5792bd5fe4d3
https://bitbucket.org/ritt/elog/commits/32ba07e19241e0bcc68aaa640833424fb3001956
https://bitbucket.org/ritt/elog/commits/15787c1edec1bbe1034b5327a9d6efa710db480b
https://bitbucket.org/ritt/elog/commits/283534d97d5a181b09960ae1f0c53dbbe42d8a90

Disclosure Timeline
12/3/2019 - Notice sent to stefan.ritt - AT - psi.ch. 90 day is March 3, 2020
12/4/2019 - Dr. Ritt acknowledges the report.
12/9/2019 - Dr. Ritt stages fixes in bitbucket.
12/9/2019 - Tenable provides feedback.
12/10/2019 - Dr. Ritt acknowledges.
12/11/2019 - Tenable reserves CVE.
12/11/2019 - Tenable notes the various ELOG instances maintained by Paul Scherrer Institute are patched.
12/11/2019 - Tenable informs Dr. Ritt and Mr. Roger Kalt (Debian/Ubuntu package manager) of intent to publish CVE tomorrow (Dec. 
12).

K.O.

Would it be possible to download attachments (e.g. with elog or wget) from the command line?

Sure. Just figure out the URL from your browser and then use it in wget, e.g.

wget https://elog.psi.ch/elogs/Forum/220309_175728/elog-3.1.4-1ebfd06c-win64.zip

to download one attachement from this forum.

Stefan

Thanks - I can confirm that the given command works.
However, for an e-log with username and password protection, this no longer seems to work.
It would be very useful if the elog command can be used to also download attachments (and not only a message).

Hello,

I do have a backup of elog repository in an external disk (with a directory name .elog). I want to install this repository to a new linux (either ubuntu 20.xx or Cent OS 7) computer. I am new to this, can someone please provide me an instructions sheet. 

Thank you

unfortunately instructions do not exist to cover every possible situation.

but in general, to migrate elog to a new machine, I would say do this:
- on new machine, install new elog from scratch
- copy the old elogs from "logbooks" on the backup disk to the new elog "logbooks"
- merge the config file by hand (this may require a few tries)

feel free to ask for more help with any of these steps here.
K.O.

> unfortunately instructions do not exist to cover every possible situation.
> 
> but in general, to migrate elog to a new machine, I would say do this:
> - on new machine, install new elog from scratch
> - copy the old elogs from "logbooks" on the backup disk to the new elog "logbooks"
> - merge the config file by hand (this may require a few tries)
> 
> feel free to ask for more help with any of these steps here.
> K.O.

Thank you so much. It worked this way. 

Dear all, 

I would need your help with an incremental index with date information.

I want to have an incremental number made by the last two digits of the year, the two digits of the month and an incremental four digits number. 

Subst Number = %y%m####

The problem is that I don't want to have the incremental number reset to zero every new month, but rather only once a year. Is it something like this possible? 

Thanks for your help! 

toto

Hello,

Is there a possibility to use like the time stamp a user stamp: by clicking the button in the main text entry it adds the username, just like the time stamp button does: Tue Apr 12 08:58:46 2022 ?

I searched but I'm not sure how this would be correctly named.

Thanks,

G

Hi,
  I'm running 
elogd 3.1.4 built Jan 27 2021, 09:56:34 revision 395e101a
on an ubuntu server.

I have a crash when very long filename (200 chars) are attached to an logbook entry.

The uploading of the attachment works almost fine: the filename is truncated and the convert to thumbnail is not working (as a consequence, maybe) but the file is actually uploaded and can be 
downloaded correctly from the entry itself.

However, if I try to access the logbook list which contains that entry, I have a crash:

*** buffer overflow detected ***: terminated
Aborted (core dumped)

[backtrace is attached below]

The only way I found to solve this is to edit manually the log entry and delete the attachment from it.

Any suggestion how to solve this?

Thanks
  Stefano


*** buffer overflow detected ***: terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bp
Undefined command: "bp".  Try "help".
(gdb) backtrace 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
#2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
#4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
#5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
#6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
#7  __GI__IO_default_xsputn (f=0x7ffffff36ca0, data=<optimized out>, n=241) at genops.c:370
#8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36ca0, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36de0, mode_flags=mode_flags@entry=6)
    at ../libio/libioP.h:948
#9  0x00007ffff7d57129 in __vsprintf_internal (
    string=0x7ffffff37120 
"../DAQ/220325_090630/j5K1OSy8XN9FRPriaBGOmMg3bih07CQKo68Sw6dskclxdOqKaTOsf2bX8UugSWn0s8zaAHe6VWiPcQVnmD8PM1tbQoVMr08dBrXKU2X2tBR4pJ3hlfxbKjspmcbiDTMy32eHIp6lFAVA9lppShmpiut4g4CtgDK3F2bOPzgzXEjPw
W0SJWG"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", args=args@entry=0x7ffffff36de0, mode_flags=6) at iovsprintf.c:95
#10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
#11 0x00005555555a939d in display_line ()
#12 0x00005555555ddc8a in show_elog_list ()
#13 0x00005555556010cf in interprete ()
#14 0x0000555555601a33 in decode_get ()
#15 0x000055555560461f in process_http_request ()
#16 0x0000555555607745 in server_loop ()
#17 0x000055555555a92c in main ()

Hi Stefano,

well, why in heaven's name do you run 200+ chars file names? I see that they are generated probably automatically, but I guess you will run in all kinds of other problems in doing that.

I had a check with elogd. I found one buffer overflow once you delete an attachment with a long file name. I fixed that and committed the change.

Concerning your crash, I was not able to reproduce it. Used a 255 char long filename, and could NOT crash elogd. Maybe you have an oder version or some special config options which
trigger that crash. Try with the newest git version and a minimal elogd.cfg configuration. Please also add line numbers during compilation (-g -o0 flags) so that I can better analyze
your backtrace. Best would be if I could reproduce your error.

Best,
Stefan



> Hi,
>   I'm running 
> elogd 3.1.4 built Jan 27 2021, 09:56:34 revision 395e101a
> on an ubuntu server.
> 
> I have a crash when very long filename (200 chars) are attached to an logbook entry.
> 
> The uploading of the attachment works almost fine: the filename is truncated and the convert to thumbnail is not working (as a consequence, maybe) but the file is actually uploaded and can be 
> downloaded correctly from the entry itself.
> 
> However, if I try to access the logbook list which contains that entry, I have a crash:
> 
> *** buffer overflow detected ***: terminated
> Aborted (core dumped)
> 
> [backtrace is attached below]
> 
> The only way I found to solve this is to edit manually the log entry and delete the attachment from it.
> 
> Any suggestion how to solve this?
> 
> Thanks
>   Stefano
> 
> 
> *** buffer overflow detected ***: terminated
> 
> Program received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bp
> Undefined command: "bp".  Try "help".
> (gdb) backtrace 
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
> #2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
> #3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
> #4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
> #5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
> #6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
> #7  __GI__IO_default_xsputn (f=0x7ffffff36ca0, data=<optimized out>, n=241) at genops.c:370
> #8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36ca0, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36de0, mode_flags=mode_flags@entry=6)
>     at ../libio/libioP.h:948
> #9  0x00007ffff7d57129 in __vsprintf_internal (
>     string=0x7ffffff37120 
> "../DAQ/220325_090630/j5K1OSy8XN9FRPriaBGOmMg3bih07CQKo68Sw6dskclxdOqKaTOsf2bX8UugSWn0s8zaAHe6VWiPcQVnmD8PM1tbQoVMr08dBrXKU2X2tBR4pJ3hlfxbKjspmcbiDTMy32eHIp6lFAVA9lppShmpiut4g4CtgDK3F2bOPzgzXEjPw
> W0SJWG"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", args=args@entry=0x7ffffff36de0, mode_flags=6) at iovsprintf.c:95
> #10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
> #11 0x00005555555a939d in display_line ()
> #12 0x00005555555ddc8a in show_elog_list ()
> #13 0x00005555556010cf in interprete ()
> #14 0x0000555555601a33 in decode_get ()
> #15 0x000055555560461f in process_http_request ()
> #16 0x0000555555607745 in server_loop ()
> #17 0x000055555555a92c in main ()

Hi Stefan,
  

> Hi Stefano,
> 
> well, why in heaven's name do you run 200+ chars file names?

This is a very good question, and I asked the same to my user: the use case is typically that the attachment names are generated programmatcally, and many steps of the script add a string to it, plus sometime the original filename has hiragana or even kanji character.

So, long story short, it has happened in our production environment

The file I'm using was indeed generated from /dev/random, but that was the earies way fo rme to create such long filename.

Backtrace with lines is as follow.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
#2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
#4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
#5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
#6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
#7  __GI__IO_default_xsputn (f=0x7ffffff36c70, data=<optimized out>, n=241) at genops.c:370
#8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36c70, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36db0, mode_flags=mode_flags@entry=6) at ../libio/libioP.h:948
#9  0x00007ffff7d57129 in __vsprintf_internal (
    string=0x7ffffff370f0 "../DAQ/220329_090332/IjU4CK54jRBuQhOdUANqC6X8i8x1yoGGKozhtuM2M0Cc8MnauDwSzAs0BiVwAIzyC4TJqmDArrIA9Exja36xXqc6PSUjOE5hkiW1YeG1R9FM64tmdq52vvo1NsqLOk6I02RBlgnQB7hoUQa1fwb8ZdoRo3BJ9WJGq2sErewo8BL9dAZhZF9"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", 
args=args@entry=0x7ffffff36db0, mode_flags=6) at iovsprintf.c:95
#10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
#11 0x00005555555a939d in sprintf (__fmt=0x555555622e74 "../%s/%s/%s", __s=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:36
#12 display_line (lbs=0x55555664b818, message_id=9, number=<optimized out>, mode=0x7ffffffd2b80 "Summary", expand=1, level=0, printable=0, n_line=3, show_attachments=0, show_att_column=1, 
    date=0x7ffffffd2a40 "Tue, 29 Mar 2022 09:03:35 +0000", in_reply_to=0x7ffffffd2a90 "", reply_to=0x7ffffffd3160 "", n_attr_disp=7, disp_attr=0x7ffffff86760, disp_attr_link=0x7ffffff386a0, attrib=0x7ffffff3d380, 
    n_attr=5, text=0x5555567f26f8 "", show_text=1, attachment=0x7ffffff3a180, encoding=0x7ffffffd2ae0 "plain", select=0, n_display=0x7ffffff38438, locked_by=0x7ffffffd2d60 "", highlight=0, re_buf=0x7ffffff38840, 
    highlight_mid=0, absolute_link=0, draft=0x7ffffffd2f60 "") at src/elogd.c:18214
#13 0x00005555555ddc8a in show_elog_list (lbs=<optimized out>, past_n=<optimized out>, last_n=<optimized out>, page_n=<optimized out>, default_page=<optimized out>, info=<optimized out>) at src/elogd.c:21741
#14 0x00005555556010cf in interprete (lbook=<optimized out>, path=<optimized out>) at src/elogd.c:28362
#15 0x0000555555601a33 in decode_get (logbook=0x7fffffffbda0 "DAQ", string=<optimized out>) at src/elogd.c:28401
#16 0x000055555560461f in process_http_request (request=<optimized out>, i_conn=<optimized out>) at src/elogd.c:29209
#17 0x0000555555607745 in server_loop () at src/elogd.c:30233
#18 0x000055555555a92c in main (argc=<optimized out>, argv=<optimized out>) at src/elogd.c:31258


I'm not using the latest git version, but elog-3.1.4-3 from tar-ball, as I'm not able to compile elog from git
Is there any special thing I have to do?

In file included from src/auth.cxx:30:
src/elogd.h:282:40: note:   initializing argument 2 of ‘int get_user_line(LOGBOOK*, char*, char*, char*, char*, BOOL*, time_t*, int*)’
  282 | int get_user_line(LOGBOOK * lbs, char *user, char *password, char *full_name, char *email,
      |                                  ~~~~~~^~~~
make: *** [Makefile:140: auth.o] Error 1

thanks for your help.

Stefano


I see that they are generated probably automatically, but I guess you will run in all kinds of other problems in doing that.
> 
> I had a check with elogd. I found one buffer overflow once you delete an attachment with a long file name. I fixed that and committed the change.
> 
> Concerning your crash, I was not able to reproduce it. Used a 255 char long filename, and could NOT crash elogd. Maybe you have an oder version or some special config options which
> trigger that crash. Try with the newest git version and a minimal elogd.cfg configuration. Please also add line numbers during compilation (-g -o0 flags) so that I can better analyze
> your backtrace. Best would be if I could reproduce your error.
> 
> Best,
> Stefan
> 
> 
> 
> > Hi,
> >   I'm running 
> > elogd 3.1.4 built Jan 27 2021, 09:56:34 revision 395e101a
> > on an ubuntu server.
> > 
> > I have a crash when very long filename (200 chars) are attached to an logbook entry.
> > 
> > The uploading of the attachment works almost fine: the filename is truncated and the convert to thumbnail is not working (as a consequence, maybe) but the file is actually uploaded and can be 
> > downloaded correctly from the entry itself.
> > 
> > However, if I try to access the logbook list which contains that entry, I have a crash:
> > 
> > *** buffer overflow detected ***: terminated
> > Aborted (core dumped)
> > 
> > [backtrace is attached below]
> > 
> > The only way I found to solve this is to edit manually the log entry and delete the attachment from it.
> > 
> > Any suggestion how to solve this?
> > 
> > Thanks
> >   Stefano
> > 
> > 
> > *** buffer overflow detected ***: terminated
> > 
> > Program received signal SIGABRT, Aborted.
> > __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> > 50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> > (gdb) bp
> > Undefined command: "bp".  Try "help".
> > (gdb) backtrace 
> > #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> > #1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
> > #2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
> > #3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
> > #4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
> > #5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
> > #6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
> > #7  __GI__IO_default_xsputn (f=0x7ffffff36ca0, data=<optimized out>, n=241) at genops.c:370
> > #8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36ca0, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36de0, mode_flags=mode_flags@entry=6)
> >     at ../libio/libioP.h:948
> > #9  0x00007ffff7d57129 in __vsprintf_internal (
> >     string=0x7ffffff37120 
> > "../DAQ/220325_090630/j5K1OSy8XN9FRPriaBGOmMg3bih07CQKo68Sw6dskclxdOqKaTOsf2bX8UugSWn0s8zaAHe6VWiPcQVnmD8PM1tbQoVMr08dBrXKU2X2tBR4pJ3hlfxbKjspmcbiDTMy32eHIp6lFAVA9lppShmpiut4g4CtgDK3F2bOPzgzXEjPw
> > W0SJWG"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", args=args@entry=0x7ffffff36de0, mode_flags=6) at iovsprintf.c:95
> > #10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
> > #11 0x00005555555a939d in display_line ()
> > #12 0x00005555555ddc8a in show_elog_list ()
> > #13 0x00005555556010cf in interprete ()
> > #14 0x0000555555601a33 in decode_get ()
> > #15 0x000055555560461f in process_http_request ()
> > #16 0x0000555555607745 in server_loop ()
> > #17 0x000055555555a92c in main ()

I recently ported an elog over to a new server running Ubuntu 20.10. Everything is working okay, except sometimes I get a strange unformatted appearance when I go to the elog page (see attachment). The happening of this seems random. For example, yesterday, when I started the elogd daemon everything looked fine, but when I log in today I get the unformatted appearance. Also, yesterday when I was setting things up, sometimes certain logbooks would have the formatting issue, and I could make this go away with a kill...restart cycle of elogd.

I downloaded the source code from here: https://elog.psi.ch/elog/download.html, selecting the elog-latest.tar.gz file.

I have tried viewing the elog on 3 different browsers (firefox, IE, Edge), result is the same every time.

Any thoughts about what the problem is?

In trying to fix this, I have re-downloaded the source from github rather than the source at http://elog.psi.ch/elog/download/tar/elog-latest.tar.gz, which is apparently very different from what is on github. Now I am running ELOG V3.1.4-d828aa58

The problem still persists, however, although only for some of the logbooks.  Curiously, it *seems* to only show up if I run elogd with the -D flag. If I just run it in the terminal, I have not seen the formatting problem (so far).

In case it's helpful, I post my elodg.cfg file.