Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 644 of 808  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Version Subjectdown
  1629   Wed Jan 25 12:10:46 2006 Reply Stefan Rittstefan.ritt@psi.chBug report 2.6.1Re: Access to global configuration in v2.6.1
> or maybe browser cookies. 

That rings a bell. If you change user permissions (like password file/no password file/rename logbooks) you might be
fooled by old cookies. Just delete all cookies in your browser and try again.
  1772   Tue Mar 14 17:11:10 2006 Reply Giorgio Croci Candianig.crocic@libero.itBug report 2.6.1Re: Access to global configuration in v2.6.1
> > or maybe browser cookies. 
> 
> That rings a bell. If you change user permissions (like password file/no password file/rename logbooks) you might be
> fooled by old cookies. Just delete all cookies in your browser and try again.

Hi,
here I am at it again. Since my first posts, I tried to install the latest version of elog out-of-the-box on one pair of
PCs from scratch (fresh elog install on new, just-installed PCs, OS WinXP Pro and Win2000), but with no results. No
trace of the global configuration menu or the buttons to reach it.
Neither taking a look at the code has helped, I could not figure out exactly where the button bar was generated.
Didn't anybody other point out a similar behaviour? Do you have any suggestion for any tests to carry out?
Thanks
GiorgioCC
  1917   Tue Aug 29 15:16:31 2006 Reply Giorgio Croci Candianig.crocic@libero.itBug reportLinux | Windows2.6.1Re: Access to global configuration in v2.6.1
Hi,
after a long time, I thought I could try to investigate the code some further,
and maybe I found some hint.
The page where I expected the options to show was (probably) the one generated by this function:

void show_admin_page(LOGBOOK * lbs, char *top_group)

Inside, it, the buttons are generated by following code snippets:

(elogd.c:10443)
if (is_admin_user_global(getparam("unm"))) {
   sprintf(str, loc("Change %s"), "[global]");
   rsprintf("<input type=submit name=cmd value=\"%s\">\n", str);
}
(elogd.c:10461)
  if (is_admin_user("global", getparam("unm"))) {
     rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Delete this logbook"));
     rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Rename this logbook"));
     rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Create new logbook"));
}

The functions called to validate the user are following:

(elogd.c:21298)
BOOL is_admin_user(char *logbook, char *user):
//...
   if (user == NULL)
      return FALSE;

(elogd.c:21324)

BOOL is_admin_user_global(char *user)
{
//...
   if (user == NULL)
      return FALSE;

Since I assume that I'm probably in the "userless" case (no users are defined in the configuration,
and no usernames are set when launching elog either), I would understand that this causes the options for
global config editing etc etc not to be shown on the admin page.

In my opinion (and given that my interpretation of the code flow isn't wrong), the "null"
user should be indeed considered admin, at least as long as no user management is defined whatsoever.
(If I got it right, if user==NULL, but a password file exists, user management is applied,
thus we're in the case of anonymous user which is correctly not admin).

Again, I might be wrong, but I would be curious to hear an opinion from you about this issue.
Thanks again for your attention.
GiorgioCC
  67265   Mon May 7 15:12:24 2012 Reply Stefan Rittstefan.ritt@psi.chInfoLinux2.9.1-2435Re: Access rights

Roland Gsell wrote:

Hi,

the manual says:

"
There are four ways through which access to a logbook may be controlled:

it may be open for all to read ;
it may require a common "read" password for all users ;
it may require each user to have an individual user account (login name) and password ;
finally, access may be granted or not depending on the address of the workstation you are using.
"

But it doesn't say how to do so or at least I didn't find it.

If I have each user have to log in with an individual accout, can I define which logbooks he can read and/or modify?
If yes, how to do that?

Also, please accept my vote for user groups. We can use that, too.

TIA,
Roland.

You haven't found it. Just look here:

http://midas.psi.ch/elog/config.html#access

 

You need Password file and Login user

  66574   Tue Nov 3 09:24:15 2009 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.77Re: Access control, group level

Niklas wrote:

Hi elog experts =)

 

Anyone know if it's possible to have access control per group-level?

For instance:

Group A = B,C   

Group B = LogA   

Group C = LogB, LogC      

Group C: Read password = abc

 //NH

I added your vote to the wishlist

https://midas.psi.ch/elog/wishlist.html 

  65879   Tue May 13 16:58:40 2008 Reply Yoshio ImaiQuestion 2.7.3-1024Re: Access Control

Grant Jeffcote wrote:
At present we can give others a full view by adding them to the 'Users' list for each individual logbook, this unfortunately also gives them 'write' access.


I think the solution to your problem would be to use Deny statements in the configuration sections for the logbooks.
Assume user1, user2 and user3 are in the "owners'" group of logbook1, and user4 and user5 only have "privileged read" access. Then a configuration as follows might help:
Login user = user1, user2, user3, user4, user5

Deny New = user4, user5
Deny Reply = user4, user5
Deny Duplicate = user4, user5
Deny Edit = user4, user5
Deny Delete = user4, user5
Deny Select = user4, user5
Deny CSV Import = user4, user5

This should give them the same read permissions as the logbook owners but should deny any writing operations. I recognize that this is a little bit of admin work if the lists of such "privileged readers" gets long, but each user would have his/her individual password (even the same as for access to his/her "own" logbook).

Perhaps you can give it a try.
  65880   Tue May 13 21:56:30 2008 Reply Grant Jeffcotegrant@jeffcote.orgQuestion 2.7.3-1024Re: Access Control

Yoshio Imai wrote:

Grant Jeffcote wrote:
At present we can give others a full view by adding them to the 'Users' list for each individual logbook, this unfortunately also gives them 'write' access.


I think the solution to your problem would be to use Deny statements in the configuration sections for the logbooks.
Assume user1, user2 and user3 are in the "owners'" group of logbook1, and user4 and user5 only have "privileged read" access. Then a configuration as follows might help:
Login user = user1, user2, user3, user4, user5

Deny New = user4, user5
Deny Reply = user4, user5
Deny Duplicate = user4, user5
Deny Edit = user4, user5
Deny Delete = user4, user5
Deny Select = user4, user5
Deny CSV Import = user4, user5

This should give them the same read permissions as the logbook owners but should deny any writing operations. I recognize that this is a little bit of admin work if the lists of such "privileged readers" gets long, but each user would have his/her individual password (even the same as for access to his/her "own" logbook).

Perhaps you can give it a try.


What a great solution, thanks Yoshio, it works a treat.
  65882   Thu May 15 17:45:44 2008 Reply Grant Jeffcotegrant@jeffcote.orgQuestion 2.7.3-1024Re: Access Control

Grant Jeffcote wrote:

Yoshio Imai wrote:

Grant Jeffcote wrote:
At present we can give others a full view by adding them to the 'Users' list for each individual logbook, this unfortunately also gives them 'write' access.


I think the solution to your problem would be to use Deny statements in the configuration sections for the logbooks.
Assume user1, user2 and user3 are in the "owners'" group of logbook1, and user4 and user5 only have "privileged read" access. Then a configuration as follows might help:
Login user = user1, user2, user3, user4, user5

Deny New = user4, user5
Deny Reply = user4, user5
Deny Duplicate = user4, user5
Deny Edit = user4, user5
Deny Delete = user4, user5
Deny Select = user4, user5
Deny CSV Import = user4, user5

This should give them the same read permissions as the logbook owners but should deny any writing operations. I recognize that this is a little bit of admin work if the lists of such "privileged readers" gets long, but each user would have his/her individual password (even the same as for access to his/her "own" logbook).

Perhaps you can give it a try.


What a great solution, thanks Yoshio, it works a treat.


Is there any way to give a logged in user a 'Guest' view on certain logbooks?
Unfortunately at the moment if they are not in the 'login users = ' group they are automatically logged out and have to re-log back into their own logbook.
ELOG V3.1.5-3fb85fa6