More questions about linux users and groups.

[Garet Jax]

This is a follow on to this thread. I didn't word the questions properly. I am going to try again here:

1) What unix file stores the users in the system?
a) If I add and remove entries from this file, is this the same as adding and removing users?

2) The other thread says that /etc/groups is the file that stores all groups and their members.
a) If I add and remove entries from this file, is this the same as adding/removing users from groups or adding/removing groups?

3) Is there a concept of permissions in unix (like permission to start/stop one or more servers or change the system time) or is all access file based?
a) If there are permissions associated with a user, what are the available permissions and where are they stored?

Thanks.

 

[Fuzznuts]

0wn3d

 

[n0cmonkey]

Originally posted by: Garet Jax
This is a follow on to this thread. I didn't word the questions properly. I am going to try again here:

1) What unix file stores the users in the system?
a) If I add and remove entries from this file, is this the same as adding and removing users?

2) The other thread says that /etc/groups is the file that stores all groups and their members.
a) If I add and remove entries from this file, is this the same as adding/removing users from groups or adding/removing groups?

3) Is there a concept of permissions in unix (like permission to start/stop one or more servers or change the system time) or is all access file based?
a) If there are permissions associated with a user, what are the available permissions and where are they stored?

Thanks.

1. Usually works fine on Linux.
2. Yes, works fine. That's how I typically add groups and add users to groups.
3. ACLs can be supported to varying degrees by different file systems and possibly with 3rd party patches.

 

[Garet Jax]

Thanks for the responses guys. I saw the passwd file, but did not know it was the user's file.

I just took a look at the group and passwd files and saw a lot of entries (the only two I knew about were root and abeaty (the user I created)). Are all these other entries required?

Can someone help break down one entry in the passwd file for me:

abeaty:x:500:501:Anthony Beaty:/home/abeaty:/bin/bash

1) Userid
2) ?
3) userid index
4) group index
5) User name
6) Home directory
7) ?

The file that starts and stops apache is owned by root and its group is root. So this means that the only user that can start and stop apache is root. If I wanted abeaty or root to be able to control apache, then I could change the owner to abeaty? Is this right?

 

[n0cmonkey]

Originally posted by: Garet Jax
Thanks for the responses guys. I saw the passwd file, but did not know it was the user's file.

I just took a look at the group and passwd files and saw a lot of entries (the only two I knew about were root and abeaty (the user I created)). Are all these other entries required?

Many of them are required. I wouldn't mess around with it unless you know what you are doing.

Can someone help break down one entry in the passwd file for me:

abeaty:x:500:501:Anthony Beaty:/home/abeaty:/bin/bash

1) Userid
2) ?
3) userid index
4) group index
5) User name
6) Home directory
7) ?

2. password (stored in /etc/shadow)
5. Real name
7. Shell

The file that starts and stops apache is owned by root and its group is root. So this means that the only user that can start and stop apache is root. If I wanted abeaty or root to be able to control apache, then I could change the owner to abeaty? Is this right?

Not exactly. Unless you have some kind of port ACLs in place, only root can bind to ports under 1024.

 

[Barnaby W. Füi]

It's not just file-based, certain syscalls can only succeed when you're root. (like settimeofday())

 

[n0cmonkey]

Originally posted by: BingBongWongFooey
It's not just file-based, certain syscalls can only succeed when you're root. (like settimeofday())

systrace helps to remedy this situation 😉

 

[Nothinman]

systrace helps to remedy this situation

As do POSIX capabilities, they've been in the kernel for quite some time but no decent userland tools have been written to support them. I think every occurance of ' if (uid != 0)' has been replaced with '(if !capable())' so the possibilities are there, they're just not exploited yet.

 

[Garet Jax]

Originally posted by: n0cmonkey
Many of them are required. I wouldn't mess around with it unless you know what you are doing.

Well that precludes me then doesn't it. 🙂 I noticed a whole bunch of them have /sbin/nologin (or something like that) under the shell. Does this mean that the user id is not valid to use as a login id?

Originally posted by: n0cmonkey
Not exactly. Unless you have some kind of port ACLs in place, only root can bind to ports under 1024.

I actually knew that somehow.

 

[Garet Jax]

Originally posted by: Nothinman

systrace helps to remedy this situation

As do POSIX capabilities, they've been in the kernel for quite some time but no decent userland tools have been written to support them. I think every occurance of ' if (uid != 0)' has been replaced with '(if !capable())' so the possibilities are there, they're just not exploited yet.

~~~~ <------- conversation

O <------- me
+
^

(supposed to represent the conversation being way over my head) 🙂

Can someone translate this and dumb it down for me? 😀

 

[n0cmonkey]

Originally posted by: Garet Jax

Originally posted by: n0cmonkey
Many of them are required. I wouldn't mess around with it unless you know what you are doing.

Well that precludes me then doesn't it. 🙂 I noticed a whole bunch of them have /sbin/nologin (or something like that) under the shell. Does this mean that the user id is not valid to use as a login id?

That is correct.

 

[n0cmonkey]

Originally posted by: Garet Jax

Originally posted by: Nothinman

systrace helps to remedy this situation

As do POSIX capabilities, they've been in the kernel for quite some time but no decent userland tools have been written to support them. I think every occurance of ' if (uid != 0)' has been replaced with '(if !capable())' so the possibilities are there, they're just not exploited yet.

~~~~ <------- conversation

O <------- me
+
^

(supposed to represent the conversation being way over my head) 🙂

Can someone translate this and dumb it down for me? 😀

POSIX is a set of standards. Nothinman said, basically, according to POSIX the capability to do things as a non-root user are currently in the kernel, but there are not many programs that support these capabilities. Systrace can do some amazing things with system calls, but it is kind of complicated.

 

[Barnaby W. Füi]

Originally posted by: Garet Jax

Originally posted by: Nothinman

systrace helps to remedy this situation

As do POSIX capabilities, they've been in the kernel for quite some time but no decent userland tools have been written to support them. I think every occurance of ' if (uid != 0)' has been replaced with '(if !capable())' so the possibilities are there, they're just not exploited yet.

~~~~ <------- conversation

O <------- me
+
^

(supposed to represent the conversation being way over my head) 🙂

Can someone translate this and dumb it down for me? 😀

uid is your user id number. Root is always uid zero. He meant that in the past, software would just do a hard check for uid of 0 (to see if you're root) to determine whether or not you're allowed to do something. Now, it calls a dynamic function that can decide whether or not you're allowed to do something based on any number of factors. (ACLs, magic server pixie dust, etc)

 

[Nothinman]

I noticed a whole bunch of them have /sbin/nologin (or something like that) under the shell. Does this mean that the user id is not valid to use as a login id?

That means that user can't get a shell via telnet, ssh, etc but it can be used for rights and other things. Like on Debian apache runs as the apache user, this means if apache gets compromised and the attacker can make apache execute things it'll only have access to things the apache user does which is usually just the web site data.