| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
576
|
Thu Jul 8 23:41:43 2004 |
 | G | levineg@med.govt.nz | Question | Linux | Other | 2.5.3 | Re: ELOG & Selection Page | Great! That takes care of the problem for sure.
Cheers once again for such a quick response.
GL.
//we use ELog very extensively internally, it's great, especially now with
replication//
> > The problem I have is I want to have a main selection type page so when a
> > user enters ELOG they see this page with links on it to main logbook groups.
>
> I added a new flag
>
> Show top groups = 1
>
> which shows the list of to groups. Hope this is what you want. The new version
> is available from CVS (see download page). |
|
741
|
Sun Oct 17 22:47:39 2004 |
| G | levineg@med.govt.nz | Question | Other | 2.5.3 | Re: ELOG e-mail notifications - their arrival time is wrong | Ok, i compiled the code below and ran it,
it prints out:
timezone: 134513644
but in BASH shell if i type DATE, then this is the output:
Mon Oct 18 09:44:00 NZDT 2004
so it does know about NZ time...
Anyone got ideas?
Thanks all.
G.
> > Date: Mon, 11 Oct 2004 12:26:28 -3736512
>
> The timezone offset (-3736512) is obtained from the "timezone" variable, which
> is initialized with the tzset() function inside elogd. See "man tzset" for
> details. It looks like if the timezone on your FreeBSD box is not correctly
> defined.
>
> Try to compile and execute following C program:
>
> #include <stdio.h>
> #include <time.h>
>
> main()
> {
> tzset();
> printf("timezone: %d\n", timezone);
> }
>
> This should print something like "timezone: -3600". If not, you might consider
> defining the "TZ" environment variable. Maybe some FreeBSD expert knows some
> details about this. |
|
1077
|
Tue Apr 12 01:05:20 2005 |
 | G | levineg@med.govt.nz | Bug report | Other | 2.5.8-3 | XML password files, replication & FreeBSD | Ok this really is 2 questions.
1)
I have been running ELOG on FreeBSD no problem for a year now,
but this new version 2.5.8-x doesn't seem to wanna work, it compiles fine
with a few warnings (see attached logs).
But has issues with password files, now it shows message "Can't open
passwords.pwd" for all my logbooks. It did convert the password files to
xml format. I had a good hard look at file permissions and config file with
no luck. So I went back a version and compiled 2.5.7-1 which works just
fine with old password files. So something with XML & FreeBSD?...
2)
Version 2.5.7-1 (maybe this has been fixed in 2.5.8?)
When I run a ./elogd -C http://elog.blah.here:88 it clones the config file
just fine, also seems to copy over all logbook entries.
But once I look through them there's a fault with one of the fields it
copies over, so entries never show up.
It should be:
========================================
Date: Tue Mar 01 19:41:29 2005
In reply to: 24
Work done by: someuser
Work done at (dd/mm/yy hh:mm): 1/03/05 3:30pm
Downtime duration: 0 min
Planned: Yes
Reason: Normal work
Attachment:
Encoding: plain
But once cloned it looks like this:
========================================
Date: Tue Mar 01 19:41:29 2005
In reply to: 24
Work done by: someuser
Work done at (dd/mm/yy hh: m): 1/03/05 3:30pm
Downtime duration: 0 min
Planned: Yes
Reason: Normal work
Attachment:
Encoding: plain
For some reason it looses the "m" so line 4 instead of having
"hh:mm" has "hh: m"
Cheers,
GL. |
| Attachment 1: compiling_ELOG_Errors_2.5.7-1.txt
|
===[root] /usr/local/elog #gmake
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elog src/elog.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o regex.o src/regex.c
src/regex.c: In function `regex_compile':
src/regex.c:1193: warning: comparison between signed and unsigned
src/regex.c:1208: warning: comparison between signed and unsigned
src/regex.c:1301: warning: comparison between signed and unsigned
src/regex.c:1326: warning: comparison between signed and unsigned
src/regex.c:1340: warning: comparison between signed and unsigned
src/regex.c:1350: warning: comparison between signed and unsigned
src/regex.c:1362: warning: comparison between signed and unsigned
src/regex.c:1368: warning: comparison between signed and unsigned
src/regex.c:1376: warning: comparison between signed and unsigned
src/regex.c:1612: warning: comparison between signed and unsigned
src/regex.c:1630: warning: suggest explicit braces to avoid ambiguous `else'
src/regex.c:1642: warning: comparison between signed and unsigned
src/regex.c:1650: warning: suggest explicit braces to avoid ambiguous `else'
src/regex.c:1686: warning: comparison between signed and unsigned
src/regex.c:1702: warning: comparison between signed and unsigned
src/regex.c:1730: warning: comparison between signed and unsigned
src/regex.c:1817: warning: comparison between signed and unsigned
src/regex.c:1930: warning: comparison between signed and unsigned
src/regex.c:1936: warning: comparison between signed and unsigned
src/regex.c:1941: warning: comparison between signed and unsigned
src/regex.c:1945: warning: comparison between signed and unsigned
src/regex.c:1949: warning: comparison between signed and unsigned
src/regex.c:1953: warning: comparison between signed and unsigned
src/regex.c:1957: warning: comparison between signed and unsigned
src/regex.c:1961: warning: comparison between signed and unsigned
src/regex.c:1979: warning: comparison between signed and unsigned
src/regex.c:2027: warning: comparison between signed and unsigned
src/regex.c:2031: warning: comparison between signed and unsigned
src/regex.c: In function `compile_range':
src/regex.c:2240: warning: comparison between signed and unsigned
src/regex.c:2242: warning: signed and unsigned type in conditional expression
src/regex.c:2242: warning: signed and unsigned type in conditional expression
src/regex.c: In function `re_match_2':
src/regex.c:3317: warning: comparison between signed and unsigned
src/regex.c:3407: warning: comparison between signed and unsigned
src/regex.c:3431: warning: comparison between signed and unsigned
src/regex.c:3470: warning: empty body in an else-statement
src/regex.c:3484: warning: comparison between signed and unsigned
src/regex.c:3500: warning: comparison between signed and unsigned
src/regex.c:3775: warning: comparison between signed and unsigned
src/regex.c:3775: warning: unused variable `destination'
src/regex.c:3922: warning: comparison between signed and unsigned
src/regex.c:3922: warning: unused variable `destination'
src/regex.c:3975: warning: comparison between signed and unsigned
src/regex.c:3975: warning: unused variable `destination'
src/regex.c:4081: warning: comparison between signed and unsigned
src/regex.c:4114: warning: comparison between signed and unsigned
src/regex.c:4114: warning: unused variable `destination'
src/regex.c:4127: warning: comparison between signed and unsigned
src/regex.c:4127: warning: unused variable `destination'
src/regex.c:4295: warning: comparison between signed and unsigned
src/regex.c: In function `regcomp':
src/regex.c:4770: warning: signed and unsigned type in conditional expression
src/regex.c: In function `regerror':
src/regex.c:4890: warning: comparison between signed and unsigned
src/regex.c: At top level:
src/regex.c:4882: warning: unused parameter 'preg'
In file included from src/regex.c:3838:
src/regex.c: In function `re_match_2':
src/regex.c:4599: warning: passing arg 1 of `bcmp_translate' discards qualifiers from pointer target type
src/regex.c:4599: warning: passing arg 2 of `bcmp_translate' discards qualifiers from pointer target type
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elogd src/elogd.c regex.o
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elconv src/elconv.c
|
| Attachment 2: compiling_ELOG_Errors_2.5.8.txt
|
===[root] /usr/local/elog-2.5.8 #gmake
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elog src/elog.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o regex.o src/regex.c
src/regex.c: In function `regex_compile':
src/regex.c:1193: warning: comparison between signed and unsigned
src/regex.c:1208: warning: comparison between signed and unsigned
src/regex.c:1301: warning: comparison between signed and unsigned
src/regex.c:1326: warning: comparison between signed and unsigned
src/regex.c:1340: warning: comparison between signed and unsigned
src/regex.c:1350: warning: comparison between signed and unsigned
src/regex.c:1362: warning: comparison between signed and unsigned
src/regex.c:1368: warning: comparison between signed and unsigned
src/regex.c:1376: warning: comparison between signed and unsigned
src/regex.c:1612: warning: comparison between signed and unsigned
src/regex.c:1630: warning: suggest explicit braces to avoid ambiguous `else'
src/regex.c:1642: warning: comparison between signed and unsigned
src/regex.c:1650: warning: suggest explicit braces to avoid ambiguous `else'
src/regex.c:1686: warning: comparison between signed and unsigned
src/regex.c:1702: warning: comparison between signed and unsigned
src/regex.c:1730: warning: comparison between signed and unsigned
src/regex.c:1817: warning: comparison between signed and unsigned
src/regex.c:1930: warning: comparison between signed and unsigned
src/regex.c:1936: warning: comparison between signed and unsigned
src/regex.c:1941: warning: comparison between signed and unsigned
src/regex.c:1945: warning: comparison between signed and unsigned
src/regex.c:1949: warning: comparison between signed and unsigned
src/regex.c:1953: warning: comparison between signed and unsigned
src/regex.c:1957: warning: comparison between signed and unsigned
src/regex.c:1961: warning: comparison between signed and unsigned
src/regex.c:1979: warning: comparison between signed and unsigned
src/regex.c:2027: warning: comparison between signed and unsigned
src/regex.c:2031: warning: comparison between signed and unsigned
src/regex.c: In function `compile_range':
src/regex.c:2240: warning: comparison between signed and unsigned
src/regex.c:2242: warning: signed and unsigned type in conditional expression
src/regex.c:2242: warning: signed and unsigned type in conditional expression
src/regex.c: In function `re_match_2':
src/regex.c:3317: warning: comparison between signed and unsigned
src/regex.c:3407: warning: comparison between signed and unsigned
src/regex.c:3431: warning: comparison between signed and unsigned
src/regex.c:3470: warning: empty body in an else-statement
src/regex.c:3484: warning: comparison between signed and unsigned
src/regex.c:3500: warning: comparison between signed and unsigned
src/regex.c:3775: warning: comparison between signed and unsigned
src/regex.c:3775: warning: unused variable `destination'
src/regex.c:3922: warning: comparison between signed and unsigned
src/regex.c:3922: warning: unused variable `destination'
src/regex.c:3975: warning: comparison between signed and unsigned
src/regex.c:3975: warning: unused variable `destination'
src/regex.c:4081: warning: comparison between signed and unsigned
src/regex.c:4114: warning: comparison between signed and unsigned
src/regex.c:4114: warning: unused variable `destination'
src/regex.c:4127: warning: comparison between signed and unsigned
src/regex.c:4127: warning: unused variable `destination'
src/regex.c:4295: warning: comparison between signed and unsigned
src/regex.c: In function `regcomp':
src/regex.c:4770: warning: signed and unsigned type in conditional expression
src/regex.c: In function `regerror':
src/regex.c:4890: warning: comparison between signed and unsigned
src/regex.c: At top level:
src/regex.c:4882: warning: unused parameter 'preg'
In file included from src/regex.c:3838:
src/regex.c: In function `re_match_2':
src/regex.c:4599: warning: passing arg 1 of `bcmp_translate' discards qualifiers from pointer target type
src/regex.c:4599: warning: passing arg 2 of `bcmp_translate' discards qualifiers from pointer target type
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -DHAVE_STRLCPY -c -o mxml.o ../mxml/mxml.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -I../mxml -o elogd src/elogd.c regex.o mxml.o
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elconv src/elconv.c
|
|
1081
|
Wed Apr 13 00:40:55 2005 |
| G | levineg@med.govt.nz | Bug report | Other | 2.5.8-3 | Re: XML password files, replication & FreeBSD | > > I have been running ELOG on FreeBSD no problem for a year now,
> > but this new version 2.5.8-x doesn't seem to wanna work, it compiles fine
> > with a few warnings (see attached logs).
> > But has issues with password files, now it shows message "Can't open
> > passwords.pwd" for all my logbooks. It did convert the password files to
> > xml format. I had a good hard look at file permissions and config file with
> > no luck. So I went back a version and compiled 2.5.7-1 which works just
> > fine with old password files. So something with XML & FreeBSD?...
>
> Hard to say. The simplest would be if I could debug this.
Anything I could send you to help debug this?
>
> > Version 2.5.7-1 (maybe this has been fixed in 2.5.8?)
> > When I run a ./elogd -C http://elog.blah.here:88 it clones the config file
> > just fine, also seems to copy over all logbook entries.
> > But once I look through them there's a fault with one of the fields it
> > copies over, so entries never show up.
> >
> > It should be:
> > ========================================
> > Date: Tue Mar 01 19:41:29 2005
> > In reply to: 24
> > Work done by: someuser
> > Work done at (dd/mm/yy hh:mm): 1/03/05 3:30pm
> > Downtime duration: 0 min
> > Planned: Yes
> > Reason: Normal work
> > Attachment:
> > Encoding: plain
> >
> > But once cloned it looks like this:
> > ========================================
> > Date: Tue Mar 01 19:41:29 2005
> > In reply to: 24
> > Work done by: someuser
> > Work done at (dd/mm/yy hh: m): 1/03/05 3:30pm
> > Downtime duration: 0 min
> > Planned: Yes
> > Reason: Normal work
> > Attachment:
> > Encoding: plain
> >
> >
> > For some reason it looses the "m" so line 4 instead of having
> > "hh:mm" has "hh: m"
>
> Your problem is that the attribute "Work done at (dd/mm/yy hh:mm)" which
> contains a ":". This character is not allowed in attributes. Unfortunately I did
> not document this (and even didn't know this until now... (;-) ). So you should
> use the new option
>
> Type Work done at = datetime
>
> this gives you at the entry mask fields for day/month/year/hour/minute to fill
> out, so you don't have to write it directly into the attribute. Another option
> would be to use
>
> Comment Work done at = Please enter as (dd/mm/yy hh:mm)
>
> which just displays a comment below the attribute in the entry mask.
>
> - Stefan
Ok, i see, the problem for me now is that this attribute name has been in use for
half a year or so by me. So now I have 100's of logbook entries with the old name
in them, if I change it's name then all old logbook entries will show up with that
field blank. I'm not sure if there's an easy way to change that attribute's name in
100's of entries in 10's of logbooks, because I wouldn't want to try doing that by
hand.. Any ideas? (i'm no good at scripting something like that 4 sure)
Thanks,
G. |
|
1636
|
Fri Jan 27 20:40:00 2006 |
| G. Vandemoortele | gvdmoort@skynet.be | Question | Linux | 2.6.1 CVS | Running elog as ordinnary user | Hello,
I've configured elog with some commands running a shell :
Preset R-Date = $shell(/usr/bin/date +"%Y/%m/%d %H:%S")
; for testing :
Preset $text = $shell(whoami && set)
Preset $text = Some fixed text
That worked well when elog was started by root (and falling to user elog),
but later, I moved all the elog tree to /home/my_name/.elog,
(I'd like to start it only when I'm logged, it's only for personnal data)
changed all the attributes/permissions ($chown -R my_name:my_group .elog)
and none of these commands still works ! I use the -x option to allow
shell substitution.
More surprisingly, even the fixed text doesn't work (???)
Any explanation ?
By the way, I also seen that it is necessary to set Usr and Grp to "elog"
via the config file even when it's started by root, because otherwise,
you always get the strings 'Falling back to default group "elog"' and
Falling back to default user "elog" in the output of the shell substitutions.
Regards,
Gauthier
|
|
1638
|
Sat Jan 28 10:40:18 2006 |
| G. Vandemoortele | gvdmoort@skynet.be | Question | Linux | 2.6.1 CVS | Re: Running elog as ordinnary user |
| Stefan Ritt wrote: |
First of all, you could use
Preset R-Date = $date
instead of the shell command. Secondly, the command
Preset $text = $shell(whoami && set)
is wrong. Replace it by
Preset text = $shell(whoami && set)
without the "$".
|
I'm sorry ; even with this correction, none of the preset strings created with
a substitution mechanism (shell or built-in) works when elogd is started as
ordinnary user. I've tried the same config file /home/gv/.elog/elogd.cfg :
port = 8080
Language = french
Main Tab = Accueil
Usr = gv
Grp = users
Logbook dir = /home/gv/.elog/logbooks
[gauthier]
Self register = 1
Password file = passwd
Theme = default
Comment = Logbook personnel
Default encoding = 1
Time format = %a, %d/%m/%Y %H:%M
Attributes = Type, Statut, Priorité, Sujet, R-Date
Preset R-Date = $shell(/usr/bin/date +"%Y/%m/%d %H:%S")
Preset text = $shell(whoami && set)
;Preset text = Blablabla
;Preset text = $date
Start page = ?rsort=Record date
List display = R-Date, Type, Statut, Priorité, Sujet
Options Type = Divers, Lectures, Musique, Aca, Finances, Santé
Options Statut = A faire, Exécuté, Journal
Options Priorité = 0, 1, 2, 3
Preset Priorité = 0
Extendable Options = Type
Thread display = $sujet ($entry time)
Required Attributes = Type, Sujet
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = R-Date, Statut, Type
Sort Attributes = Priorité, R-Date
Started via root (# /usr/sbin/elogd -c /home/gv/.elog/elogd.cfg -x), it works,
but via "gv" ($ /usr/sbin/elogd -c /home/gv/.elog/elogd.cfg -x), it doesn't.
Regards,
Gauthier |
|
69299
|
Wed Feb 3 17:28:16 2021 |
| Gabriel Lopez | gabelopez@bnl.gov | Bug report | Linux | 3.1.4 | 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 |
| Gabriel Lopez | gabelopez@bnl.gov | Bug report | Linux | 3.1.4 | 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: |
|
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).
|
|
|
|
|
|