Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 58 of 807  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Show attachments  Show only new entries    6451 Entries 
Goto page Previous  1, 2, 3 ... 57, 58, 59 ... 805, 806, 807   Next  
IDdown Date Icon Author Author Email Category OS ELOG Version Subject
  69407   Mon Nov 1 12:52:23 2021 Question David Stopsdjs@star.sr.bham.ac.ukQuestionLinuxelog-3.1.4-2results of security scan

Recently central IT scanned our elog server and reported the following "vulnerabilities"

  • 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
  • 51192 (1) - SSL Certificate Cannot Be Trusted
  • 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
  • 85582 (1) - Web Application Potentially Vulnerable to Clickjacking

Is there any easy way of preventing these

Thanks and Best Wishes

David

  69406   Tue Oct 26 01:21:01 2021 Question Rob Calkinsrcalkins@smu.eduQuestionLinux3.1.4While mirroring, data fields not preserved

While running two e-log books that were mirrored, I ended up with the situation of two entries with the same number/id.  The mirroring did what it said it would, increment the local logbook entry and grab the entry from the remote logbook. However, when it did, it did not preserve the fields in the log book that are specified in the config file such as "Author", "Priority", "Subject" ect.  I ended up with a very minimal log:

  69404   Mon Oct 25 13:34:06 2021 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.1.4 Re: Too many open files - issue?

The code segements you show are from the command line tool elog.c, not the server elogd.c. The tool is called to submit a new message from the command line. Even if there would be a file not properly closed, it will be closed by the operating system once the program finishes. So no problem of too many open files there.

Rob Calkins wrote:

Has anyone had issues with having too many files open? I'll setup my server and let it go but after a while, I end up with a lot of "cannot create socket: Too many open files" errors being reported.  I have a sync to another e-log going which I suspect is part of the cause since that e-log server hasn't had this issue. I suspect that there are files being opened, going into some return loop code and then never getting closed. I'm not a C programmer but I see lines like :

fh = open(tmp_filename, O_RDONLY);
      if (fh > 0) {
         read(fh, result, size - 1);
         close(fh);
      }

      /* remove temporary file */
      remove(tmp_filename);

This looks like it opens the file but unless the remove function closes the file, it will remain open even through the file has been deleted. Maybe this isn't the correct behaviour of 'remove' and I am mistaken?

There are also parts like :

 fh = open(textfile, O_RDONLY | O_BINARY);
      if (fh < 0) {
         printf("Message file \"%s\" does not exist.\n", textfile);
         return 1;
      }

      size = (INT) lseek(fh, 0, SEEK_END);
      lseek(fh, 0, SEEK_SET);

      if (size > (INT) (sizeof(text) - 1)) {
         printf("Message file \"%s\" is too long (%zd bytes max).\n", textfile, sizeof(text));
         return 1;
      }
This looks like for the second error, it will complain that the file is too long, return an error message but not close the file and would leave it open. Is this a reasonable avenue to pursue or am I mis-reading the code?   Thanks.

 

  69403   Thu Oct 21 15:19:16 2021 Reply Chris Körnerchris.koerner@physik.uni-halle.deBug reportLinux3.14Re: wrong server HTTP status code when login failed

Seems like I've discovered another bug here related to umlauts in my name. :D 

I was submitting this post and forgot to put an icon. Elog seems to have saved a copy of my message, which I could not edit since my username does not match the bugged name saved for this message.

Chris Körner wrote:

Hi,

I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view and post messages. However, if a wrong user/password is provided, the server still returns HTTP status code "200 OK", although login failed. Instead, it should return something like "401 Unauthorized". This behavior later causes problems since the python client thinks login was successful. After experimenting around I think this could be caused by a server side misconfiguration. Any ideas?

I am not sure if this imformation is important: We use LDAP as user/password provider for elog.

 

  69402   Thu Oct 21 15:17:52 2021 Question Chris Körnerchris.koerner@physik.uni-halle.deBug reportLinux3.14wrong server HTTP status code when login failed

Hi,

I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view and post messages. However, if a wrong user/password is provided, the server still returns HTTP status code "200 OK", although login failed. Instead, it should return something like "401 Unauthorized". This behavior later causes problems since the python client thinks login was successful. After experimenting around I think this could be caused by a server side misconfiguration. Any ideas?

I am not sure if this imformation is important: We use LDAP as user/password provider for elog.

  Draft   Thu Oct 21 14:57:14 2021  Chris Körnerchris.koerner@physik.uni-halle.deBug reportLinux3.14wrong server HTTP status code when login failed

Hi,

I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view and post messages. However, if a wrong user/password is provided, the server still returns HTTP status code "200 OK", although login failed. Instead, it should return something like "401 Unauthorized". This behavior later causes problems since the python client thinks login was successful. After experimenting around I think this could be caused by a server side misconfiguration. Any ideas?

I am not sure if this imformation is important: We use LDAP as user/password provider for elog.

  69400   Thu Oct 21 11:15:20 2021 Idea Andreas Luedekeandreas.luedeke@psi.chRequestAll3.1.4How about string constants in config files?

My config files are often large and use some shell scripting. In these shell scripting part I interact with files and execute scripts in specific folder.
It would be nice to have the ability to define for example a file path once and reuse it in different parts of the config file. It would help to make config files cleaner. For example:

Constant c_cid = "/usr/local/elog/logbooks/elog-campaignID.default"
Execute new = if ! [ -z "$CampaignID" ] ; then echo "$CampaignID" > $c_cid; fi

Preset CampaignID = $shell( if [ -r $c_cid ] ; then cat $c_cid; else echo None > $c_cid; echo None; fi )

  69399   Thu Oct 21 11:00:46 2021 Warning Andreas Luedekeandreas.luedeke@psi.chBug reportLinux3.1.4-2e1708bRedirect in Execute new needs space after ">"

EDIT: forget the tip below. Instead just call script files: inline scripting in the ELOG config shows very strange behavior. Doing the same in external scripts works reliable.

 

I just spend an hour searching for a problem. To avoid others to spend the hour again, here's a little "special behaviour" of shell execution in ELOG you should know about:

If you want to do redirect to a file in a shell execution, put a space before and after the redirecting. The following does not work:

Execute new = if ! [ -z "$CampaignID" ] ; then echo "$CampaignID" >/usr/local/elog/logbooks/elog-campaign.default ; fi

You will not get an error message, but the file is not created. But if you add a space it will work as expected:

Execute new = if ! [ -z "$CampaignID" ] ; then echo "$CampaignID" > /usr/local/elog/logbooks/elog-campaign.default ; fi

It is not really a bug; if you know about it, then it is not a big deal: hence this entry here. I saw this behavior on a Linux RHEL7 system.

In case you are wondering: I use this to create a default for the field CampaignID, to be used for new entries in combination with a Preset:

Preset CampaignID = $shell( if [ -r /usr/local/elog/logbooks/elog-campaign.default ] ; then cat /usr/local/elog/logbooks/elog-campaign.default;fi )
Goto page Previous  1, 2, 3 ... 57, 58, 59 ... 805, 806, 807   Next  
ELOG V3.1.5-3fb85fa6