ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67320
|
Tue Aug 28 23:02:07 2012 |
| Szu-Ching Peckner | speckner@nd.edu | Question | Linux | latest | secure way to allow users create logbook | I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves? |
67324
|
Wed Aug 29 14:35:45 2012 |
| Szu-Ching Peckner | speckner@nd.edu | Question | Linux | latest | Re: secure way to allow users create logbook |
Stefan Ritt wrote: |
Szu-Ching Peckner wrote: |
I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves?
|
Actually there is no good secure way. What I usually do is to give users admin rights on individual logbooks, then they can change the config of that logbook. Many times adding some attribute is as good as creating new logbooks. Like if you need two logbooks "home" and "work", you can create an attribute "type" and let the type be "home" or "work". With conditional attributes you can make the logbook behave differently for the two values of "type" and get most functionality of two separate logbooks.
- Stefan
|
Thanks, that is good option. |
67326
|
Wed Aug 29 18:16:37 2012 |
| Szu-Ching Peckner | speckner@nd.edu | Question | Linux | latest | Re: secure way to allow users create logbook |
Stefan Ritt wrote: |
Szu-Ching Peckner wrote: |
I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves?
|
Actually there is no good secure way. What I usually do is to give users admin rights on individual logbooks, then they can change the config of that logbook. Many times adding some attribute is as good as creating new logbooks. Like if you need two logbooks "home" and "work", you can create an attribute "type" and let the type be "home" or "work". With conditional attributes you can make the logbook behave differently for the two values of "type" and get most functionality of two separate logbooks.
- Stefan
|
Is there a way to set user permission based on certain attribute? can Allow command = <user list> based on attribute?
for example, say type home, user1 can read, user2 can write, user3 can not access type home, but can access type work.
In short, is access control available when I use type to get functionality of separate logbooks? If so, how is this access control done?
|
67330
|
Thu Aug 30 22:47:50 2012 |
| Szu-Ching Peckner | speckner@nd.edu | Question | Linux | latest | Re: secure way to allow users create logbook |
Stefan Ritt wrote: |
Szu-Ching Peckner wrote: |
Stefan Ritt wrote: |
Szu-Ching Peckner wrote: |
I don't think there is a good secure way so far, but would like to have your opinion.
If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves?
|
Actually there is no good secure way. What I usually do is to give users admin rights on individual logbooks, then they can change the config of that logbook. Many times adding some attribute is as good as creating new logbooks. Like if you need two logbooks "home" and "work", you can create an attribute "type" and let the type be "home" or "work". With conditional attributes you can make the logbook behave differently for the two values of "type" and get most functionality of two separate logbooks.
- Stefan
|
Is there a way to set user permission based on certain attribute? can Allow command = <user list> based on attribute?
for example, say type home, user1 can read, user2 can write, user3 can not access type home, but can access type work.
In short, is access control available when I use type to get functionality of separate logbooks? If so, how is this access control done?
|
Actually I never tried that. Using conditional attributes, you could try that out, but no guarantee that it works. Like
Options type = home{1}, work{2}
{1}Login user = you, me
{2}Login user = me, other
You could play with "login user", "Allow command" and "Deny command".
/Stefan
|
Thanks for reply Stefan.
I tried it, didnt work. I think its expected it didn't work though, or maybe I didn't try it right.
==============
[logbook1]
Login user = user1
Options Type = Home{1}, Work{2}
{1} Login user = user2
This will make user2 unable to login logbook1 at all
============
[logbook1]
Login user = user1, user2
Options Type = Home{1}, Work{2}
{1} Login user = user1
{2} Login user = user2
user1 can login, can search Work type entries, create new entry with Work type.
==============
[logbook1]
Login user = user1, user2
Options Type = Home{1}, Work{2}
{1} Deny New = user1
user1 can still create entries for Home type. I think it's because when user1 login, command New is available for user1, so when user1 click on New, doesn't matter what type user1 choose, submit button is available. If I have Deny New = user1 under logbook1, New is not available, that means user1 can't create entry for Work type either.
===============
seems to me under current code, access control has to be done based on logbook, not attribute. Do you agree?
if that's the case, we may have a lot of logbook because of access control we want to implement. So there is another question:
selection page show all logbooks. Is there a way to make selection page and tabs show logbooks based on user access?
For example, we have 20 logbooks, user1 has acces to 3, when user1 login, selection page only shows that 3 logbooks for user1, and only 3 tabs for user1.
I thought about using group to get logbooks more organized, however I will still face the situation that one group may have 20 logbooks.
Or what would you do to handle this situation? (I asked selection page question earlier in another entry). Maybe we should discuss on that entry? Message ID: 67319
Thanks again.
|
67342
|
Tue Sep 18 17:57:47 2012 |
| Szu-Ching Peckner | speckner@nd.edu | Question | Linux | latest | admin user access admin page, not config page | We have multiple logbooks. Each user is admin user for his/her own logbook.
I want user be able to modify config file, but no access to user setting, such as see user list, change password, new user, remove user.
[logbook1]
Admin user = user1
Login user = user1, user2
Allow Config = user1
List Menu commands = Admin, Config
user1 click on Admin, it opens config file, when user1 click on save, user1 is brought to Config page, which has select user list on top, Change password, Remove user, New user buttons on bottom. Is there a way that admin user has access to config file, but no access to user info at all (not even presented to them). Is there a way after user1 click save, page doesn't go to that config page?
I could put
Deny Change password =
Deny Remove user
Deny New user
so when user1 click on those buttons, user1 will get command not allowed. However I would rather have user1 not even see that page.
|
68699
|
Fri Nov 17 18:58:52 2017 |
| Susan James | sjames@lbl.gov | Question | Linux | 3.1.2-bd7 | hosts allow | I'm trying to wrap our elog instance to our company domain which is lbl.gov
I add this entry below (without quotes) to elogd.cfg and it's not working. the world can see our logbooks
" Hosts Allow = *.lbl.gov ".
can someone help?
|
68701
|
Tue Nov 21 01:27:06 2017 |
| Susan James | sjames@lbl.gov | Question | Linux | 3.1.2-bd7 | Re: hosts allow | thanks for your quick reply.
the configuration is still not working. See my entry below which denies everyone.
I've tried many different combinations of 'hosts allow and hosts deny'
we want to restrict all our logbooks to only domain lbl.gov
[ below denies ALL ]
Hosts allow = .lbl.gov
Hosts deny = ALL
[ below denies ALL ]
Hosts deny = ALL
Hosts allow = .lbl.gov
Can you help?
Andreas Luedeke wrote: |
Hi Susan,
according to the documentation you need to add "Hosts deny = All" in addition to the "Hosts allow" command.
Here is the relevant excerpt from the documentation (https://midas.psi.ch/elog/config.html#access).
Cheers
Andreas
Hosts allow = <list>
Hosts deny = <list>
These two settings can be used to restrict the access to the logbook to certain computers. It is similar to the UNIX hosts.allow and hosts.deny files. The list can consist of individual host names or IP numbers, subnet masks like 123.213. (note the trailing '.') or .mit.edu , or the word All . The following rules are applied:
- Access will be granted when a host matches a pattern in "hosts allow".
- Otherwise, access will be denied when a host matches a pattern in "hosts deny".
- Otherwise, access will be granted.
These rules are applied before any password is checked. To debug problems, start elogd with the "-v" flag, in which case the rule checking is printed on the screen.
Susan James wrote: |
I'm trying to wrap our elog instance to our company domain which is lbl.gov
I add this entry below (without quotes) to elogd.cfg and it's not working. the world can see our logbooks
" Hosts Allow = *.lbl.gov ".
can someone help?
|
|
|
68710
|
Thu Dec 7 21:54:58 2017 |
| Susan James | sjames@lbl.gov | Question | Linux | 3.1.2-bd7 | Re: hosts allow | Hi All,
We're still having trouble with hosts.allow and hosts.deny.
We're trying to allow all of our domain lbl.gov to the access list
for our logbooks. But the combination below is not working.
==========================
[ below denies ALL ]
Hosts allow = .lbl.gov
Hosts deny = ALL
[ below denies ALL ]
Hosts deny = ALL
Hosts allow = .lbl.gov
========================
Can someone help?
Susan James wrote: |
thanks for your quick reply.
the configuration is still not working. See my entry below which denies everyone.
I've tried many different combinations of 'hosts allow and hosts deny'
we want to restrict all our logbooks to only domain lbl.gov
[ below denies ALL ]
Hosts allow = .lbl.gov
Hosts deny = ALL
[ below denies ALL ]
Hosts deny = ALL
Hosts allow = .lbl.gov
Can you help?
Andreas Luedeke wrote: |
Hi Susan,
according to the documentation you need to add "Hosts deny = All" in addition to the "Hosts allow" command.
Here is the relevant excerpt from the documentation (https://midas.psi.ch/elog/config.html#access).
Cheers
Andreas
Hosts allow = <list>
Hosts deny = <list>
These two settings can be used to restrict the access to the logbook to certain computers. It is similar to the UNIX hosts.allow and hosts.deny files. The list can consist of individual host names or IP numbers, subnet masks like 123.213. (note the trailing '.') or .mit.edu , or the word All . The following rules are applied:
- Access will be granted when a host matches a pattern in "hosts allow".
- Otherwise, access will be denied when a host matches a pattern in "hosts deny".
- Otherwise, access will be granted.
These rules are applied before any password is checked. To debug problems, start elogd with the "-v" flag, in which case the rule checking is printed on the screen.
Susan James wrote: |
I'm trying to wrap our elog instance to our company domain which is lbl.gov
I add this entry below (without quotes) to elogd.cfg and it's not working. the world can see our logbooks
" Hosts Allow = *.lbl.gov ".
can someone help?
|
|
|
|
|