ELOG Forum

Demo Discussion

Forum Config Examples Contributions Vulnerabilities

Discussion forum about ELOG, Page 556 of 808

Not logged in

Find | Login | Help

Full | Summary | Threaded | Hide attachments

6457 Entries

Goto page Previous 1, 2, 3 ... 555, 556, 557 ... 806, 807, 808 Next

Author Email down

Wed Oct 30 17:57:38 2013

Fabio Sella

gaia-gc@altecspace.it

Question

Linux

2.9.2-1

kerberos authentication NOT working

Hi guys,

we configured a kdc server using OPENLDAP as backend. We installed on it elog and configured the Kerberos Authentication on one logbook as follows:

Authentication = Kerberos, File
Kerberos Realm = TEST.COM
Password file = ./pwd.xml

Even if the kinit comand is retrieving correctly a ticket for the user tsearch@TEST.COM(we see it using klist and tcpdump on lo interface), elogd kerberos authentication is not working.

We tried using tcpdump for troubleshooting but no traffic is generated on the loopback interface.

Did someone solve this problem or do you have an idea on how to make the kerberos authentication working?

Thanks

1746

Sat Mar 4 05:17:14 2006

require smileys to have whitespace on either side?

It would be nice if elog would only interpret something as a smiley if it is surrounded by whitespace. It can be particularly annoying that an 8 followed by a right paren becomes a "cool" smiley -- e.g., a parenthetical reference to event eighteen (18) becomes mangled... [That was "18" inside the parens.]

Is there already a way to solve this issue (other than always previewing your entries and adding spaces before parans)? Is the feature hard to implement?

1760

Mon Mar 6 20:51:57 2006

Provide option to require smileys to be bracketed a la ELCode?

Stefan Ritt wrote:

Glenn Horton-Smith wrote:

Interpreting smileys only if they are surrounded by whitespace does not solve the problem completely. It will solve it for (1\8), but not if you have (1, \8) (1, 9) in your text. So it's not a good solution. If you have problems with simleys, I would post my text in plain mode, or surround your numbers with [code]...[/code] tags...

Hmm, you're right. But I like EL Code, and I don't want to give it up just because of the smileys! A better solution would be to provide an option, which when set, would require smileys to be in brackets, e.g., [\8)] would become the cool smiley [8)], rendered without surrounding brackets if the option was set.

I actually just spent some time I didn't really have and modified my copy of elogd to see if it could be done and would work as intended. Eureka, it works! The modification implements an option "use bracketed smileys" which, if set to 1, causes the editor smiley bar to insert smileys with the square brackets around them and causes rsputs_elcode() to only substitute for smileys if there are square brackets around them, suppressing the square brackets.

I like this feature. Maybe others would like it too. I have a patch file (diff -cbw) w.r.t. svn version 1663 if you're interested.

66885

Fri Aug 27 23:11:45 2010

Synchronizing mirror causes corruption of logbook entries with multiple logbooks defined?

We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it?

Details

We have two elog servers set up with identical elogd.cfg and password files, except that one server has "Mirror server" pointing to the other host. There are three logbooks defined. (Their names are DoubleChooz, BigBrotherTable, and FlushingTable.) When the mirror synchronization happens, whether by "Mirror cron" or by an administrator hitting the "Synchronize all logbooks" link, it often happens that entries requiring synchronization are corrupted on both servers (not just the one to which the entry was copied). This is particularly likely to happen if entries have been made on both servers since the previous sync.

Looking at the logbook files themselves, we see that the corrupted entries will have attributes from the wrong logbooks. E.g., we'll see an empty "Barometer: " line in a DoubleChooz logbook file, where "Barometer" is an attribute that is only in the FlushingTable logbook, or we will see there are unexpected DoubleChooz logbook attributes in the FlushingTable files.

Strangely, the entries will not be identical on the two machines after syncing, and they stay non-identical on further syncs.

Most disturbingly, data is lost from entries that were perfectly valid before the sync, on both servers.

This was happening with elogd 2.7.8, and continued to happen after upgrading to 2.8.0. Both servers are running Linux. One is a 32-bit machine and another 64-bit, in case that might matter (but read on).

I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized. This suggests it isn't specific to Linux architecture, 64-bit or otherwise.

68651

Sun Jul 30 07:39:23 2017

Enable LDAP on Windows

Hi All,

I'm running ELOG on a Windows machine and I would like to use LDAP for Authentication, however to achive this I need to compile elog. Any advice on how to do that on Windows?

Thanks!

69299

Wed Feb 3 17:28:16 2021

Re: Path disclosure on unfound file

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

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:

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

=====

My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.

====

(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).

69365

Thu May 20 21:01:41 2021

Running elog-3.1.4-3 Can't add users through the web interface. Clicking add user and writing all the fields in with something doesn't add a user into the PWD file of that logbook. Running a tail -f on the password file shows elog writes the user info with the hashed password 3 times and then deletes the information about 20 seconds later. Has anyone else had a similar issue? This is running on RHEL8.3

Goto page Previous 1, 2, 3 ... 555, 556, 557 ... 806, 807, 808 Next

ELOG V3.1.5-3fb85fa6