Re: once a week we are having elogd segault?, posted by mathew goebel on Wed Aug 6 17:08:46 2025
|
We have since discovered that the security team is scanning the box in question once a week when the service crashes, with nexpose.
So if you see something similar then you might want to explore that.
mathew goebel wrote: |
Jul 17 20:36:21 elog kernel: elogd[179095]: segfault at 7ffda4d82000 ip 00007f97033a1406 sp 00007ffda4d58c38 error 6 in libc-2.28.so[7f9703374000+1cd000]
Elog version ELOG V3.1.5-30ada1df
Running on a Rehdat 8 enterprise server
compiled with a Makefile change :: change -Wno-unused-result to -Wno-unused-value
Wondering if anyone has been seeing this?
|
|
Re: once a week we are having elogd segault?, posted by Stefan Ritt on Thu Aug 7 11:04:39 2025
|
Probably some very strange URL form nexpose to trigger a potential buffer overflow. If I get the precise URL which crashes elogd, I can reproduce and fix it.
Otherwise my usual advice: Run elogd behind an Apache proxy and do the authentication there. This way nexpose does not get to elogd, it will stop at the Apache (without the proper credentials).
Steafn
mathew goebel wrote: |
We have since discovered that the security team is scanning the box in question once a week when the service crashes, with nexpose.
So if you see something similar then you might want to explore that.
mathew goebel wrote: |
Jul 17 20:36:21 elog kernel: elogd[179095]: segfault at 7ffda4d82000 ip 00007f97033a1406 sp 00007ffda4d58c38 error 6 in libc-2.28.so[7f9703374000+1cd000]
Elog version ELOG V3.1.5-30ada1df
Running on a Rehdat 8 enterprise server
compiled with a Makefile change :: change -Wno-unused-result to -Wno-unused-value
Wondering if anyone has been seeing this?
|
|
|
[global] config still editable by admin of top group, posted by Damian Goeldi on Mon Sep 15 13:16:58 2025
|
The ETH physics department is running an ELOG behind an Apache reverse proxy:
ProxyPass / http://localhost:$port/ retry=0
ProxyPassReverse / http://localhost:$port/
ProxyAddHeaders off
Authentication is done on the Apache side using LDAP authentication, example:
<Location /demo>
Use PhysLDAP
AuthType Basic
AuthBasicProvider ldap
...
Require valid-user
RewriteEngine On
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1,NS]
RequestHeader add X-Forwarded-User %{RU}e
</Location>
And all ELOGs use the following config:
[demo]
Authentication = Webserver
For the PSI-Praktikum we had to create a logbook that is accessible without an ETH-Account. A new logbook was added, which is not authenticated via the proxy, but the ELOG internal authentication. In order to grant access to the students, I was made admin for that logbook. The configuration is the following:
[PSI-Praktikum]
Authentication = File
Password file = /home/wwwelog/private/password/psi-praktikum.xml
Admin user = damian
In order to prevent my user from editing the global configuration, top groups according to https://elog.psi.ch/elog/config.html#groups were introduced, with one top group for all the proxy-authenticated logbooks, and a separate one for the Praktikum logbook. However, even after doing this, I am still able to edit the [global] section. Is there a way to prevent this? Or is it not possible to have a global section that is not accessible by the top group admins? |
Re: [global] config still editable by admin of top group, posted by Stefan Ritt on Mon Sep 15 15:11:41 2025
|
You can have authentication via the Webserver or the ELOG internal one, but this is on a global level for all logbooks. You cannot mix this between logbooks. For that, you would have to run two instances of ELOG at two different ports.
Stefan
Damian Goeldi wrote: |
The ETH physics department is running an ELOG behind an Apache reverse proxy:
ProxyPass / http://localhost:$port/ retry=0
ProxyPassReverse / http://localhost:$port/
ProxyAddHeaders off
Authentication is done on the Apache side using LDAP authentication, example:
<Location /demo>
Use PhysLDAP
AuthType Basic
AuthBasicProvider ldap
...
Require valid-user
RewriteEngine On
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1,NS]
RequestHeader add X-Forwarded-User %{RU}e
</Location>
And all ELOGs use the following config:
[demo]
Authentication = Webserver
For the PSI-Praktikum we had to create a logbook that is accessible without an ETH-Account. A new logbook was added, which is not authenticated via the proxy, but the ELOG internal authentication. In order to grant access to the students, I was made admin for that logbook. The configuration is the following:
[PSI-Praktikum]
Authentication = File
Password file = /home/wwwelog/private/password/psi-praktikum.xml
Admin user = damian
In order to prevent my user from editing the global configuration, top groups according to https://elog.psi.ch/elog/config.html#groups were introduced, with one top group for all the proxy-authenticated logbooks, and a separate one for the Praktikum logbook. However, even after doing this, I am still able to edit the [global] section. Is there a way to prevent this? Or is it not possible to have a global section that is not accessible by the top group admins?
|
|
Re: [global] config still editable by admin of top group, posted by Konstantin Olchanski on Wed Sep 17 21:55:57 2025
|
Another idea, if you have root access to the elog server, you can temporarily make the elog config file unwritable to the elog user, nobody will be
able to change it from the web interface. (and as root, you can edit it using emacs). But in general case, yes, it is better to setup a separate
elog instance for what you do. Still, make the config elog unwritable by the elog user, so it cannot be hacked too easily. K.O. |
ELOG Skins Showcase, posted by Tomas Rudolf on Sat May 3 11:08:11 2003
|
Hello everybody.
I am sure that some of you (just like me) experimented already with themes
and especially now with .CSS in order to give ELOG a different "look"
and "feel".
I was wondering if we could maybe share examples of such adapted
ELOG's .CSS files (or themes). Maybe you can take a screen shot of your
favorite ELOG "face" (no sensitive data, of course) and post it here as an
attachement. Or is everybody using only the original look that Stefan
delivers as default?
Let's share some inspiration. I'll post mine as soon as finished the re-
look.
Tomas |
Re: ELOG Skins Showcase, posted by Stefan Ritt on Sat May 3 15:06:16 2003
|
> Let's share some inspiration. I'll post mine as soon as finished the re-
> look.
Excellent idea. I added a category "CSS File" in the logbook "Config
Examples" next to this forum. You can login with the same user name and
password as for this forum. As an example, I posted the new CSS file. Please
note that one need small changes in elogd.c to accomodate for the new 3D
look (basically don't display lines between cells), so it won't work very
nice with pre-2.3.7.
So everybody is invited to post his favourite CSS files an icons there.
Maybe we can even make a competition about the nicest ELOG icon... |
syntax highligting for elog.cfg with ULTRAEDIT, posted by Etienne Van Caillie on Wed May 21 10:15:17 2003
|
UltraEdit Syntax coloring
=========================
add this file in ultraedit
UltraEdit --> ADVANCED --> CONFIGURATION --> SYNTAX HIGHLIGHTING
I hope this will help you...
it gives different color according to elog commands
some attributes are use internaly like
ShellOnSubmit
ShellParam
if somebody has other suggestion to improve the display ask me |