Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 373 of 807  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Version Subject
  66831   Fri May 21 14:37:26 2010 Entry Allenbastss@rit.eduQuestionLinux2.7.8Restricting logbook view

Is there anyway to restrict access so that a user can only see the log entries they post or only replies to their log entry?  I know it is possible to restrict editing to only posts they submitted, but I have a need to not even allow them to see other posts except for what they submitted and I am wondering if this is possible currently, or if this is planned, or could be planned for a future version?


Thanks,

 

Allen

  66830   Thu May 20 04:33:07 2010 Reply A. Martinamartin@example.comBug reportAllsvnRe: attachment filename bug & Makefile issue


> > If I upload the file "000000_000000_file.txt", elog will chop the filename to "file.txt."  Also, this effects
> > the file's displayed "Uploaded" time.  It shows the file as being uploaded on: "Tue Nov 30 00:00:00 1999"
> 
> Arghh! Why did you choose such a filename? This is the ELOG internal file format, which is YYMMDD_HHMMSS_name.ext. 
> For internal reasons (mainly for synchronization) the system checks every file name, and if it contains 6 numbers 
> followed by a "_" followed by 6 other numbers it thinks it's a valid date/time and uses that. Your time is however 
> 0.0.0000, that's why it gets converted to some date in 1999. Do you absolutely need this functionality? While I can 
> easily remove the interpretation of the date, it would break the synchronization functionality and I would have to 
> find some other method to pass the file date/time, which would be quite some work. So if it's not too important for 
> you, I would like to keep it as it is.
> 

Thank you for your response.  

I can certainly use another filename, but I'm curious why elog doesn't convert the filename "000000_000000_file.txt" to
"YYMMDD_HHMMSS_000000_000000_file.txt" when it gets uploaded.  All other files are automatically prepended with this
string.  Manually renaming the file and then editing the elog entry via text editor seems to fix the file.

thanks,
amartin
  66829   Thu May 20 03:37:59 2010 Reply John Rouillardrouilj+elog@cs.umb.eduBug reportLinux | Other2.7.8Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

Stefan Ritt wrote:

John Rouillard wrote:
Ok, so this patch fixes the problem on the client side (rather than the server side like my patch) of the
cloning process. I can't tell from the patch above but will this fix allow the cloning process to "complete"
but without the password file being copied, or does code outside the patched section try to login and get
the password file?


Well, why don't you give it a try and let me know if the is any problem left?


Sorry to report that it fails same as originally with:
  Received invalid response from elogd server at http://example.org:8080/Discussion/

However there was a fuzz of 12 lines when I applied the patch, but I think it got the right line.

-- rouilj
  66828   Wed May 19 09:57:50 2010 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux | Other2.7.8Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

John Rouillard wrote:
Ok, so this patch fixes the problem on the client side (rather than the server side like my patch) of the
cloning process. I can't tell from the patch above but will this fix allow the cloning process to "complete"
but without the password file being copied, or does code outside the patched section try to login and get
the password file?


Well, why don't you give it a try and let me know if the is any problem left?
  66827   Tue May 18 21:17:35 2010 Reply John Rouillardrouilj+elog@cs.umb.eduBug reportLinux | Other2.7.8Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

Stefan Ritt wrote:

Ok, now I got it! The problem was that you used "Guest menu commands = ..." and I did not. So the behavior is different with that option, which is why I could not reproduce your problem initially. Now I could reproduce it and the cleanest fix is this:
--- elogd.c     (revision 2294)
+++ elogd.c     (working copy)
@@ -15704,7 +15704,7 @@
          fgets(pwd, sizeof(pwd), stdin);
          while (pwd[strlen(pwd) - 1] == '\n' || pwd[strlen(pwd) - 1] == '\r')
             pwd[strlen(pwd) - 1] = 0;
-      } else if (status != 200 && status != 302) {
+      } else if (status != 200 && status != 302 && status != 404) {
          xfree(buffer);
          *strchr(str, '?') = 0;

which is just accept the 404 response and not abort the cloning process.


Yup. My settings are:
Guest menu commands = List, Last 10, Find, Login, Help
Guest List Menu commands = List, Last 10, Find, Login, Help

Ok, so this patch fixes the problem on the client side (rather than the server side like my patch) of the
cloning process. I can't tell from the patch above but will this fix allow the cloning process to "complete"
but without the password file being copied, or does code outside the patched section try to login and get
the password file?

-- rouilj
  66826   Tue May 18 16:40:15 2010 Reply Stefan Rittstefan.ritt@psi.chBug reportAllsvnRe: attachment filename bug & Makefile issue
> If I upload the file "000000_000000_file.txt", elog will chop the filename to "file.txt."  Also, this effects
> the file's displayed "Uploaded" time.  It shows the file as being uploaded on: "Tue Nov 30 00:00:00 1999"

Arghh! Why did you choose such a filename? This is the ELOG internal file format, which is YYMMDD_HHMMSS_name.ext. 
For internal reasons (mainly for synchronization) the system checks every file name, and if it contains 6 numbers 
followed by a "_" followed by 6 other numbers it thinks it's a valid date/time and uses that. Your time is however 
0.0.0000, that's why it gets converted to some date in 1999. Do you absolutely need this functionality? While I can 
easily remove the interpretation of the date, it would break the synchronization functionality and I would have to 
find some other method to pass the file date/time, which would be quite some work. So if it's not too important for 
you, I would like to keep it as it is.

> Makefile has the line:
> 
> # flag for SSL support
> USE_SSL    = 1
> 
> However setting USE_SSL = 0 does not prevent the openssl libraries from being used.  Same issue with USE_CRYPT.
>  You have to comment them out.
> 
> Lines 76-85 of Makefile should be replaced with this:
> 
> ifdef USE_SSL
> ifneq ($(USE_SSL), 0)
> CFLAGS += -DHAVE_SSL
> LIBS += -lssl
> endif
> endif
> 
> ifdef USE_CRYPT
> ifneq ($(USE_CRYPT), 0)
> CFLAGS += -DHAVE_CRYPT
> LIBS += -lcrypt
> endif
> endif

The original idea was that one outcomments the whole line, like

#USE_SSL = 1

which always worked, but I agree that your solution is more general, so I changed the official Makefile. Thanks for 
that.
  66825   Tue May 18 13:21:32 2010 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux | Other2.7.8Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

John Rouillard wrote:

John Rouillard wrote:

I think I kind of see what's happening here. In is_command_allowed you add the GetPwdFile to the list of
allowed command but only if is_admin_user is true. Since the user is guest at that point, I assume
is_admin_user returns false making is_command_allowed return false. Then the redirect is attempted by this
code sequence:
  if (!is_command_allowed(lbs, command)) {
      /* redirect to login page for new command */
      if (strieq(command, loc("New")) && !isparam("unm")) {
         check_user_password(lbs, "", "", _cmdline);
         return;
      }
but to me that looks like it will execute only if the command contains the word new
(or it's translated equivalent if I understand loc() properly)?? Since the command string
GetPwdFile doesn't match no login screen is presented by check_user_password.


The attached patch (also included inline) seems to fix the problem. I am sure it can be done more cleanly but...
--- elogd.c~    2009-12-02 05:53:44.000000000 -0500
+++ elogd.c     2010-05-16 21:58:14.000000000 -0400
@@ -26236,6 +26236,10 @@
          check_user_password(lbs, "", "", _cmdline);
          return;
       }
+      if (strieq(command, loc("GetPwdFile")) && !isparam("unm")) {
+         check_user_password(lbs, "", "", _cmdline);
+         return;
+      }
 
       strencode2(str2, command, sizeof(str3));
       sprintf(str, loc("Error: Command \"<b>%s</b>\" not allowed"), str2);

-- rouilj


Ok, now I got it! The problem was that you used "Guest menu commands = ..." and I did not. So the behavior is different with that option, which is why I could not reproduce your problem initially. Now I could reproduce it and the cleanest fix is this:
--- elogd.c     (revision 2294)
+++ elogd.c     (working copy)
@@ -15704,7 +15704,7 @@
          fgets(pwd, sizeof(pwd), stdin);
          while (pwd[strlen(pwd) - 1] == '\n' || pwd[strlen(pwd) - 1] == '\r')
             pwd[strlen(pwd) - 1] = 0;
-      } else if (status != 200 && status != 302) {
+      } else if (status != 200 && status != 302 && status != 404) {
          xfree(buffer);
          *strchr(str, '?') = 0;

which is just accept the 404 response and not abort the cloning process.
  66824   Mon May 17 04:19:29 2010 Reply John Rouillardrouilj+elog@cs.umb.eduBug reportLinux | Other2.7.8Re: elogd -C failing to sync password file with "Received invalid response from elogd server" message

John Rouillard wrote:

I think I kind of see what's happening here. In is_command_allowed you add the GetPwdFile to the list of
allowed command but only if is_admin_user is true. Since the user is guest at that point, I assume
is_admin_user returns false making is_command_allowed return false. Then the redirect is attempted by this
code sequence:
  if (!is_command_allowed(lbs, command)) {
      /* redirect to login page for new command */
      if (strieq(command, loc("New")) && !isparam("unm")) {
         check_user_password(lbs, "", "", _cmdline);
         return;
      }
but to me that looks like it will execute only if the command contains the word new
(or it's translated equivalent if I understand loc() properly)?? Since the command string
GetPwdFile doesn't match no login screen is presented by check_user_password.


The attached patch (also included inline) seems to fix the problem. I am sure it can be done more cleanly but...
--- elogd.c~    2009-12-02 05:53:44.000000000 -0500
+++ elogd.c     2010-05-16 21:58:14.000000000 -0400
@@ -26236,6 +26236,10 @@
          check_user_password(lbs, "", "", _cmdline);
          return;
       }
+      if (strieq(command, loc("GetPwdFile")) && !isparam("unm")) {
+         check_user_password(lbs, "", "", _cmdline);
+         return;
+      }
 
       strencode2(str2, command, sizeof(str3));
       sprintf(str, loc("Error: Command \"<b>%s</b>\" not allowed"), str2);

-- rouilj
Attachment 1: elog_GetPwdFile_diff.patch
--- elogd.c~	2009-12-02 05:53:44.000000000 -0500
+++ elogd.c	2010-05-16 21:58:14.000000000 -0400
@@ -26236,6 +26236,10 @@
          check_user_password(lbs, "", "", _cmdline);
          return;
       }
+      if (strieq(command, loc("GetPwdFile")) && !isparam("unm")) {
+         check_user_password(lbs, "", "", _cmdline);
+         return;
+      }
 
       strencode2(str2, command, sizeof(str3));
       sprintf(str, loc("Error: Command \"<b>%s</b>\" not allowed"), str2);
ELOG V3.1.5-3fb85fa6