kecoak
asked on
UID = 0 , and GID = 0
I knew that root is : UID = 0 and GID = 0
Suppose that If I want to add another user than has the same abilitiy/priviledge as root.
Should
1) I assign <newuser> with UID = 0 and GID = 0 too?
2) What is the different between <newUser> -> UID = 0 and GID = not 0
with <newUSER> -> UID = not 0 and GID 0
What is the implication of both case?
Suppose that If I want to add another user than has the same abilitiy/priviledge as root.
Should
1) I assign <newuser> with UID = 0 and GID = 0 too?
2) What is the different between <newUser> -> UID = 0 and GID = not 0
with <newUSER> -> UID = not 0 and GID 0
What is the implication of both case?
ASKER
Can you confirm this
Say I have the following user : XYZ , UID = 0 , GID = 520, it will have the same priviledge as Root(UID:0, GID =0)??
Say I have the following user : XYZ , UID = 0 , GID = 520, it will have the same priviledge as Root(UID:0, GID =0)??
Yes it will for editing and accessing files.........but if an application changes the running permission of the process to the GID of the user, rather than the UID of the user, then there may be some interesting issues here. For example:
The shutdown command on my system is UID 6, GID 0 - Not sure about the actual code internally, but if it decides to take the GID of the person issuing a command to it, and then try and shutdown as GID 520, then I suspect that the end result will not be as expected.
You'd have to have a good look at the source code in order to find all the potential issues.
I have to confess that I've never seen a need to do this. It might be worth having a good look to see if there are better ways of doing what you want. In particular, you may wish to have a look at Security Enhanced Linux, where you can define exactly what a user can and cannot do in a much more fine grained manner:
http://www.securityenhancedlinux.com/
It's included in the newer redhat distros.
HTH:)
The shutdown command on my system is UID 6, GID 0 - Not sure about the actual code internally, but if it decides to take the GID of the person issuing a command to it, and then try and shutdown as GID 520, then I suspect that the end result will not be as expected.
You'd have to have a good look at the source code in order to find all the potential issues.
I have to confess that I've never seen a need to do this. It might be worth having a good look to see if there are better ways of doing what you want. In particular, you may wish to have a look at Security Enhanced Linux, where you can define exactly what a user can and cannot do in a much more fine grained manner:
http://www.securityenhancedlinux.com/
It's included in the newer redhat distros.
HTH:)
> Should 1) I assign <newuser> with UID = 0 and GID = 0 too?
no
even this works in most situations, all programs which reliy on UID will fail
If you want to have users to have the same permissions as root, then use sudo
> 2) What is the different between <newUser>
silly question, silly answer: the number
UID, GID 0 is reserved for root, and should not be assign to any other user/group, for obvious security reason
no
even this works in most situations, all programs which reliy on UID will fail
If you want to have users to have the same permissions as root, then use sudo
> 2) What is the different between <newUser>
silly question, silly answer: the number
UID, GID 0 is reserved for root, and should not be assign to any other user/group, for obvious security reason
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi kecoak,
Be carefull when giving UID and GID as 0 because when you change this user's password, the root password will be also changed.
I would suggest you to use "sudo", it is more secure and you will have control of what which user is executing.
I hope it helps. =0)
Be carefull when giving UID and GID as 0 because when you change this user's password, the root password will be also changed.
I would suggest you to use "sudo", it is more secure and you will have control of what which user is executing.
I hope it helps. =0)
> Be carefull when giving UID and GID as 0 because when you change this user's password, the root password will be also changed.
no!
yes, sometimes, somehow!
see my comment http:#16621924
no!
yes, sometimes, somehow!
see my comment http:#16621924
Sorry, but yes or no?
I have already had this problem.
I have already had this problem.
> Sorry, but yes or no?
depends
As I said (see comment) it depends on the programs, hence I'd never recommend using 0 for anything else than root. It's a dirty hack for people who 101% know what they do and who 101% know what might happen.
depends
As I said (see comment) it depends on the programs, hence I'd never recommend using 0 for anything else than root. It's a dirty hack for people who 101% know what they do and who 101% know what might happen.
ASKER
The advantages of giving them the Root password or using SUDO instead of creating another account
with UID 0 is...
(1) They will clearly login as themselves -- the logs will clearly show who logged in, and when you view
logged in users, you will be able to tell how they got in.
-----------------
I agree with this bit, but there is no point having good audit logs in here since if you were root you can modify the logs file anyway? Therefore there is no accountability.
> Therefore there is no accountability.
that's why SELinux have been mentioned already
other possibilities are grsecurity or App Amor
that's why SELinux have been mentioned already
other possibilities are grsecurity or App Amor
>I agree with this bit, but there is no point having good audit logs in here since if you were root you can modify the logs file >anyway? Therefore there is no accountability.
False.
1. That root can modify the logs is no reason not to have them in the first place -- the fact that root CAN
modify them does not mean that root deliberately forges them.
Depending on the circumstances, the other root may not know about all the logging that is done.
Accountability is partly about having an idea and having information about what goes on normally,
when other roots are well behaved too.
2. A considerable effort would be required to modify the logs enough to make them useless.
3. Modifying the logs can itself leave a trail.
4. The logs could be stored on a different machine, or multiple backups could be made by the time the
other user could attempt to modify them.
--
Just because it is theoretically possible for someone to forge your signature on a document, does not
make contracts and othe such documents useless.
By the same token, just because it's possible for someone to maliciously forge, alter, or erase
a log entry, does not make system logging useless.
False.
1. That root can modify the logs is no reason not to have them in the first place -- the fact that root CAN
modify them does not mean that root deliberately forges them.
Depending on the circumstances, the other root may not know about all the logging that is done.
Accountability is partly about having an idea and having information about what goes on normally,
when other roots are well behaved too.
2. A considerable effort would be required to modify the logs enough to make them useless.
3. Modifying the logs can itself leave a trail.
4. The logs could be stored on a different machine, or multiple backups could be made by the time the
other user could attempt to modify them.
--
Just because it is theoretically possible for someone to forge your signature on a document, does not
make contracts and othe such documents useless.
By the same token, just because it's possible for someone to maliciously forge, alter, or erase
a log entry, does not make system logging useless.
2. It is the UID of 0 that grants 'root' status and it can read any file, whereas the GID of 0 only (having just tried it out) to provide 'root' group status (i.e access to files where root the root group is the owner and has access priviledges, and therefore will not be able to access files owned by say user1 where there is no permission for GID 0 to read them.
Effectively, that means that your user with UID of say 501 and GID of zero could carry out some administrative tasks, but would be unable to view files of rwx------ belonging to someone else.
HTH:)