Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
A user can be a member of more than one group simultaneously. Just add the user name to each group he/she should be a part of in /etc/group. The next time that user logs in, they will have access to each group they are a part of without having to explicitly change group.
When the user logs in, they will be assigned to a default group. Any files created will belong to that default group. You can change this with the newgrp command (man newgrp). That command does not influence access concerns as mentioned before; it simply changes the group assigned to newly created files or directories.
It could be a permissions problem or a PATH problem. Give an example if you don't mind. Give the output of an "ls -l" command for one or more of the commands you are trying to execute, and the output of "echo $PATH" for the user.
I've never tried it, but changing a user's ID to 0 would essentially create an alias for root. I honestly don't know how the system would handle it, and would strongly advise against it. It's a security risk (there are now two "accounts" with super user privileges, and likely, two different passwords -> more passwords for the same access = bad). To me, there's no point in it. I've warned off some new users from it. They understood the "don't run as root" policy, but they were frustrated with having to "su" or "sudo". So, in a twist of logic, they wanted to create another account to avoid that, and give it root permissions. So, by a technicality, they weren't running as "root" but the effect was the same. A root account by any other name...
Well, you have to understand that the operating system doesn't keep track of accounts by name. The system uses your user ID for things such as access to files, logging events and so on. The text names for accounts is simply something for us, as users, to remember easier than a user ID.
With that in mind, run a thought experiment on the idea of allowing root to view a log of changes made by this other user (we'll call the new user "admin"). Three things come to mind:
First, since admin has the same user ID as root, what would the logs print for the username? root or admin? Since the root account is typically the first account listed in your /etc/passwd file, then my money would say that the logs would enter "root" as the username for actions taken by root or admin. That would not be very effective in tracking the admin user's activities.
Second, if the log filters out entries for the "root" account, then it certainly won't include entries for admin because they both have the same ID, and if the filter removes messages based on root's ID, then it will also remove admin's. The only reason I mention this is because I got the impression the logging either didn't include root and you felt it would include any other user, or you needed some distinction between the activities of root and admin (which would lead back to the problem in #1).
Third, assuming that root and admin's activities are logged and that the system has some way of distinguishing between them, then what's to prevent admin from opening the log and editing its contents? I'm assuming the whole idea for root to watch the log is to "spy" on admin's activities, implying that the admin account is not fully "trusted". So the security mechanism is flawed since admin has the ability to modify or erase his/her records in the log.
I'm not trying to come down on you or anything; just outlining what would likely happen if you tried it. Using su or sudo are much safer. Of the two, sudo is probably the best because it allows root to specify exactly what commands a given user can execute. You can even set it to run the allowed command(s) without asking for a password, but that poses other security issues. Having to type the password may seem like a pain, but you get used it it, and eventually, it actually helps. More than once I've issued a sudo command and in the time it took me to enter the password, I realized there was a typo in the command, a bad argument, or something similar. So then I just simply Ctrl-C'ed sudo and saved myself some pain of having to fix te damage that screwed up command would have caused.
Did you figure out the problem? I haven't seen you post anything regarding your original problem to help clear up what might be the cause.
Last edited by Dark_Helmet; 06-08-2004 at 02:28 AM.
Some one correct me if Iam wrong ! But i dont think belonging to the group which has got root as a use is going to give you root privileges. That is solely held by root and rightly so.
As Dark_Helmet outlined so clearly, there is no point in having two root accounts. In the same manner even if your UID is part of the same group as root, it doesnt mean you will have root privileges, you might have some privileges, but certainly not enough for a shutdown !!
I recently added two users to my system. I wnat to give them the ability
to shutdown/ reboot without having to su to root, so I added them to
the /etc/sudoers file:
user1 MachineName = NOPASSWD: /sbin/halt, /sbin/shutdown, /sbin/reboot