Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 529 of 808  Not logged in ELOG logo
icon1.gif   bug in elog.spec, posted by Janusz Szuba on Mon Jul 6 19:09:48 2020 

Hi, 

in commit 1812e7c, specifying CFLAGS to make command in elog.spec, renders all other settings in Makefile void. That is, if I want to include any of KRB5, LDAP, PAM support, and change makefile accordingly, then when producing rpm they are not taken into account. Anyway, CFLAGS in Makefile are already set to the same defaults, so why it is redefined in spec file?

best

Janusz

    icon2.gif   Re: bug in elog.spec, posted by Janusz Szuba on Tue Jul 7 11:22:45 2020 

Thanks for the answer, I will try with your specfile

best

Janusz

Laurent Jean-Rigaud wrote:

Hi,

You rights, CFLAGS should not be in specfile to take care of distrib env.

Btw, I sent in the past an update for build process of Stefan delivery to generate src.rpm file copatible to tarball version. I think Stefan did not have time yet to test and to check.

With the enclosed SPEC file, you can build ELOG with options at rpmbulld command w/o modifying sources. For exemple,

rpm -i elog-.....src.rpm

rpmbuild -bb --with ssl --with pam --with ldap --with krb5 ~/rpmbuild/SPECS/elog.spec

 

I enclosed also the SRPMS i used for my projects. Be careful, It's maybe not uptodate of last GIT version or PSI releases... but you can test it on your RPM distrib. It should be nice to hare your feedback.

Bye,

Laurent

 

Janusz Szuba wrote:

Hi, 

in commit 1812e7c, specifying CFLAGS to make command in elog.spec, renders all other settings in Makefile void. That is, if I want to include any of KRB5, LDAP, PAM support, and change makefile accordingly, then when producing rpm they are not taken into account. Anyway, CFLAGS in Makefile are already set to the same defaults, so why it is redefined in spec file?

best

Janusz

 

 

icon5.gif   Deny option and Guest commands, posted by Janusz Szuba on Mon Jul 19 18:41:29 2021 

Hi, 

I have a logbook with guest access and guest can also enter a new entry (in config: Guest List Menu commands = New, Find, Select, Login). For other reason in a global section, I put 

Deny New = account1, account2

This somehow invalidates Guest List Menu commands, since as guest I don't see New button anymore. Is this behaviour desired? Otherwise, I would need to move Deny option to plenty of individual logbook configs. Just to explain the reason, those accounts are set up to only read entries and not to create new ones. Or maybe you can suggest a different solution?

Best

icon1.gif   "New User" option does not work when Authentication=Webserver, posted by Jan Just Keijser on Fri May 29 09:27:32 2020 

Our setup uses "Authentication=Webserver" + no automatic user registration. Thus, logbook admins should add a user by clicking "Config"  and then "New user". However, no matter what they fill in in the "new user " dialog, as soon as they hit "Save" an error pops up saying that their username (the admin one, not the new one) already exists. I found the following code:

int save_user_config(LOGBOOK * lbs, char *user, BOOL new_user)
{
   char file_name[256], str[256], *pl, user_enc[256], new_pwd[80], new_pwd2[80], smtp_host[256],
       email_addr[256], mail_from[256], mail_from_name[256], subject[256], mail_text[2000], str2[256],
       admin_user[80], url[256], error[2000], sid[32];
   int i, self_register, code, first_user;
   PMXML_NODE node, subnode, npwd; 

   /* if we outsourced the authentication, use external username */
   getcfg(lbs->name, "Authentication", str, sizeof(str));
   if (stristr(str, "Webserver")) {
      /* do not allow HTML in user name */
      strencode2(user_enc, http_user, sizeof(user_enc));
   } else {
      strencode2(user_enc, user, sizeof(user_enc));
   }

 

which seems to be the culprit:  the admin user is logged using his/her Webserver (http_user) credentials and this overrides anything that he/she might fill in.  If I remove the "Authentication" check then I can create a new user without problems.  So, how to fix this? should the "Authentication=Webserver" check be extended with a self/auto registration check?

 

    icon2.gif   Re: "New User" option does not work when Authentication=Webserver, posted by Jan Just Keijser on Wed Aug 18 09:05:51 2021 elog-webauth.patch

here's the patch that I use to enable  use creation and deletion in combination with Webserver authentication.

The idea behind the patch is that if the user logged in via  "http_user" is an elog admin, then {s}he is allowed to save a random user configuration, including creating or deleting a user.

Stefan Ritt wrote:

Unfortunately I locallly don't have Webserver authentication, so I cannot check or debug. If you send me a diff that works for you, I'm happy to incorporate it.

Stefan

Jan Just Keijser wrote:

Our setup uses "Authentication=Webserver" + no automatic user registration. Thus, logbook admins should add a user by clicking "Config"  and then "New user". However, no matter what they fill in in the "new user " dialog, as soon as they hit "Save" an error pops up saying that their username (the admin one, not the new one) already exists. I found the following code:

int save_user_config(LOGBOOK * lbs, char *user, BOOL new_user)
{
   char file_name[256], str[256], *pl, user_enc[256], new_pwd[80], new_pwd2[80], smtp_host[256],
       email_addr[256], mail_from[256], mail_from_name[256], subject[256], mail_text[2000], str2[256],
       admin_user[80], url[256], error[2000], sid[32];
   int i, self_register, code, first_user;
   PMXML_NODE node, subnode, npwd; 

   /* if we outsourced the authentication, use external username */
   getcfg(lbs->name, "Authentication", str, sizeof(str));
   if (stristr(str, "Webserver")) {
      /* do not allow HTML in user name */
      strencode2(user_enc, http_user, sizeof(user_enc));
   } else {
      strencode2(user_enc, user, sizeof(user_enc));
   }

 

which seems to be the culprit:  the admin user is logged using his/her Webserver (http_user) credentials and this overrides anything that he/she might fill in.  If I remove the "Authentication" check then I can create a new user without problems.  So, how to fix this? should the "Authentication=Webserver" check be extended with a self/auto registration check?

 

 

 

icon3.gif   Default "Author" when replying to a log entry, posted by Jan Just Keijser on Tue Feb 1 15:39:38 2022 

what is the default value for "Author" when replying to a log entry ?  I now see that for each reply to a log entry, the value of "Author" is set to the value of the author of the original entry - this makes it very hard to see which user has replied to a particular log entry, especially when users start replying to replies etc.

This is with elog 3.1.4-3 on CentOS 7

    icon2.gif   Re: Default "Author" when replying to a log entry, posted by Jan Just Keijser on Tue Feb 1 16:43:34 2022 

Excellent, exactly what I was looking for, many thanks!

 

Stefan Ritt wrote:

As you can see, on this forum the author for replies is correct. This is done via the config option:

Preset on reply Author = $long_name

Jan Just Keijser wrote:

what is the default value for "Author" when replying to a log entry ?  I now see that for each reply to a log entry, the value of "Author" is set to the value of the author of the original entry - this makes it very hard to see which user has replied to a particular log entry, especially when users start replying to replies etc.

This is with elog 3.1.4-3 on CentOS 7

 

 

    icon2.gif   Re: Vulnerability?, posted by Jan Just Keijser on Mon Mar 7 17:46:39 2022 
> > 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.
ELOG V3.1.5-3fb85fa6