Hi guys,
at the moment we are setting up a SLES 11 SP2 in our testing area for a customer project. We want to use a SLES 11 SP2 as management server for a central user authentication. So far so good.
We setted up an LDAP Server and another SLES 11 SP2 guestsystem in our VMWare-farm as a LDAP Client. We can add LDAP users to the LDAP server without any problems, but if we want to add the user to an additional local group “root” we don’t have “root” privileges after re-login with the LDAP user. I don’t have write privileges to any files in /etc or anywhere - only read privileges.
Maybe one of you know the issue and how I can solve this problem.
Best regards,
Michael
wsdatenservice,
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
Has your issue been resolved? If not, you might try one of the following options:
Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.suse.com/faq.php
If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.
Good luck!
Your SUSE Forums Team
http://forums.suse.com
[QUOTE=wsdatenservice;4501]We setted up an LDAP Server and another SLES 11 SP2 guestsystem in our VMWare-farm as a LDAP Client. We can add LDAP users to the LDAP server without any problems, but if we want to add the user to an additional local group “root” we don’t have “root” privileges after re-login with the LDAP user. I don’t have write privileges to any files in /etc or anywhere - only read privileges.
[/QUOTE]
Hi Michael,
Do a Google search on “Linux file permissions”. There are lots of sites that will explain how file permissions work.
If you look at the file permissions for /etc, and most of the files in that directory, you will see that the root user has write permissions but members of the root group only have read and execute permissions.
Normally you don’t want to give other users access to files that are owned by root.
What are you trying to accomplish?
[QUOTE=KBOYLE;4705]
Normally you don’t want to give other users access to files that are owned by root.
What are you trying to accomplish?[/QUOTE]
Hi KBOYLE,
maybe you already read, we want accomplish a management server for the user authentication over LDAP. The users should log in with their named-user accounts. For example: User John Smith should be able to log-in with his user account “jsmith”. He should be able to start/stop/re-start services or change some settings in /etc/apache2/sites-available/hostfile. To do that he require root privileges. Some other users should be able to start YaST2.
We need named-users for auditing. There should be no more changes made from the root user. It should be clearly visible, who executed/changed what at what time.
Regards,
Michael
wsdatenservice wrote:
[color=blue]
We need named-users for auditing. There should be no more changes made
from the root user. It should be clearly visible, who executed/changed
what at what time.[/color]
Hi Michael,
The only thing I can think of is this:
http://www.suse.com/products/suse-manager/features/simplify_compliance.html
I don’t know how you would accomplish what you want if you only rely on
file permissions.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are using the web interface,
show your appreciation and click on the star below…
Hi Michael,
you typically won’t be able to audit the changes made by an individual user even if you set up access permissions on a per-user basis. You will see that the file was changed, when the file was changed, but not who changed the file nor what that user changed.
Taking that into account, you could only try to monitor those changes on an individual basis by creating “wrappers” to the file modification, i.e. scripts (or “real programs”) that are invoked by the individual user but run with superuser privileges (“suid-programs”), which is the most complicated way. Maybe the product mentioned by Kevin is such a wrapper (I have no experience with that extension).
If monitoring program invocations is sufficient, you could take a closer look at “sudo”: You can setup up which individual user may invoke which program in what user context (i.e. calling a program as a root user), so the invoker does not need to know the root account details, but can act as root. Of course, you need to make sure that the invoked programs don’t allow extra or even sub-shell operations that will let the user escape the “jail”: Worst case would be to permit calling “bash” in the root user context 
“sudo” can be administred via LDAP entries and does log individual invocations to syslog.
maybe you already read, we want accomplish a management server for the user authentication over LDAP.
That was so vage, only the notification daemon bothered to answer And your reply contained a totally different description from your first post… “It should be clearly visible, who executed/changed what at what time.” was not part of your initial query (and is a major task, as you by now have learned). Kevin’'s comment was right on the spot: By adding your users to the “root” group, you precisely got what you requested from the system: They additionally got access to the files as granted to the group “root”. Which has nothing to do with the permissions of the “root” user. (Might it be that you’re coming from a world where roles are mostly granted to groups? Historically, unixoid systems grant execute/read/write permissions, which has nothing to do with roles. And the uid “0”, typically associated with the user named “root”, even has hard-coded exceptions to that.)
Regards,
Jens