I've been using and administering programs running on Linux systems for probably two years or longer, but luckily, I've never had to worry about permissions and users. Now I'm in a situation where I'll be administering a BIND server, and the user permissions issue has raised its head. I guess my question relates in some degree to a lack of understanding of chmod , but principally, it relates to a failure on my part to understand the conceptual framework of Linux permissions, which I hope someone can give me some pointers on.


From the perspective of administering a Win2k server, permissions seem fairly straightforward. You have users, and groups. Every user is a member of one or more groups. Virtually every system resource has an ACL, to which any given user or group can be added or removed. Any individual user, or group of users, can be assigned any level of permissions on any resources anywhere in the file system

My understanding of groups and permissions in Linux is that the landscape is very different. You still have users and groups, and every user is still a member of one or more groups. However, system resources have permissions only for the owner (in almost every case i.e., but sometimes e.g., the resource's creator), the owner's group, and everyone who isn't the owner or i the owner's group.

This seems to me to make a laberynthine nightmare a permissions request that is simple under the Win2k model. As noted before, I'm administering a BIND server on RH9; virtualy all of the important files relating to Bind are owned by root. If I want to create one or more administrative accounts that have RWX access to /etc/named.conf, /etc/rc.d/init.d/named, and all files in the directory /var/named/master, my understanding coming from a Win2k perspective would be to create a user (or group of users), and set the ACL on each of the above-named files and directories to allow those users to have RWX permissions for that resource. In Linux, this doesn't seem possible.

In this case, I suppose it is arguable that I could change the owner of each of these files to a user named-supremo, a member of the group named-admins, create other accounts in that group, and run chmod 775, but a) I don't necessarily want to do that, b) one can foresee numerous situations beyond this one example where one wants to assign permissions to users on certain files without wanting to add the user to a given group or change the owner of a resource.


Another example would be that I have three files: paper, scissors and stone. I have three users, mickey, goofey and donald. mickey owns paper and scissors, root owns stone. I want to give goofey rwx permissions on paper, scissors and stone, and donald wrx permissions on paper and stone, but only rx permissions on scissors. Any other user should only have rx permissions on paper and stone, but only r permissions on scissors.

In Windows, I'd just assign goofey rwx permissions on paper, scissors and stone, and assign donald rwx permissions on paper and stone, rx permissions on scissors.

In Linux, as it seems to me, goofey has easy requirements. Make him a member of mickey's group. However, to give donald wrx permissions on paper, I either have to make him a member of the same group as mickey, or change the any user permissions for paper, which I don't want to do! But I can't make donald a member of mickey's group, because then either donald gets wrx permissions for scissors (remembering that goofey has and should have access to scissors, as a member of mickey's group) or I have to deny rwx permissions for group permissions on scissors.


I guess what I'm saying is that if I'm understanding Linux right, directory security is necessarily about groups and owners, and there is no detailed control over individual nightmares. I have to maintain an elaborate scheme of which users are in which groups and which groups have permissions on what objects; any unforeseen security requirements may mean adding a dozen users to a completely new group, whose permissions may conflict with existing requirements. This makes no sense to me.

Am I missing some really huge chunk of understanding, because this to my mind is perfectly potty. To my understanding - to me, as someone who uses Linux, likes Linux, and would move a lot more of the services we run over to Linux if that was my choice, so in every way someone pro-Linux - my understanding of Linux permissions vs. Windows permissions is that Linux permissions are no-where near as flexible as Windows permissions. This doesn't seem to square against everything else I know about Linux vs. Windows, in which Linux is vastly more flexible than Windows, hence the question: quite aside from the command syntax, which is well-documented, am I missing something, conceptually, here?


My standard references are Using Linux System Administration (Danesh & Das, Que 2000) and Linux Complete (Aulds, Danesh, Hontanon, Hunt, Minasi, Pfaffenberger, Smith, Stanfield & Wells, Sybex 2002). Neither of these include a particularly good discussion of this subject material, and the same is true of most of the web resources. All of these sources provide discussion of the technical minutiae - chmod , chgrp and so on - but lack a strong conceptual framework to explain directory security and permissions in a Linux paradigm to those used to the same subject but from a Windows paradigm.

I'm not here having a dig at Linux permissions; I freely confess that this problem is born of my own lack of understanding of the mindset I need to view Linux permissions from. If anyone could offer guidelines or reccomend links / books that they found helpful, I'd appreciate it.



Regards,
Simon

chmod

Hi, and welcome to LQ!

I won't take quite as much time and many words as you to
give you a working scenario for the bind problem... :) I will
ignore the two blokes with the three names for my sanity's
sake, too ;)

What you want to do is create a group dnsadmin (or the
like), and just
chgrp -r dnsadmin /etc/named.conf /etc/rc.d/init.d/named /var/named/master
chmod g+rw /etc/named.conf
chmod -R g+rwx /etc/rc.d/init.d/named /var/named/master
and make the fellas member of that group. There's no need
to take roots ownership away.

With that scenario both root and the jokers in dnsadmin
can edit configuration files, and all of them can start/stop/restart
the service for the change to take effect.

As for the potty-ness of Linux' permissions: experience
and performance to me justify the approach, my Linux
boxes without complex ACL's outperform any other server
system I ever dealt with.



Cheers,
Tink

Tinkster,
Thanks for the reply, I appreciate the help. I think I see what you're saying, but only within the scope of this example.

Trying your suggestion on a test file, I do this:

Create a group called bind-admins and assign an admin user to it:

[root@linux1 master]# /usr/sbin/groupadd -g 501 bind-admins
[root@linux1 master]# /usr/sbin/usermod -Gbind-admins shawn


The unmodified file:

[root@linux1 named]# ls -l named.conf.test
-rw-r--r-- 1 root root 14647 Jul 28 15:34 named.conf.test


Then I change the group ownership of the file:

[root@linux1 named]# chgrp -v bind-admins named.conf.test
changed group of `named.conf.test' to bind-admins
[root@linux1 named]# ls -l named.conf.test
-rw-r--r-- 1 root bind-admins 14647 Jul 28 15:34 named.conf.test


And lastly change the group permissions:

[root@linux1 named]# chmod g+rw named.conf.test
[root@linux1 named]# ls -l named.conf.test
-rw-rw-r-- 1 root bind-admins 14647 Jul 28 15:34 named.conf.test

This is good, insofar as now, both root and any users in the bind-admins group can read and write to named.conf.test, while any other users can simply view it. So this does solve the immediate quandry, and I guess the missing bit of information on my part was that you can change the group ownership without changing the owner. However, it still seems to me that this approach, when looked at in a wider field, has problems.

For example:

If I want to make one of my staff a junior bind admin, with permission to stop, start and reload the name server, then that junior admin needs rwx access to two files: /usr/sbin/rndc and /etc/rc.d/init.d.named. Because I've changed the group ownership of those files to the group bind-admins, making that user a member of bind-admins will give them permission to do what we want them to do. However, it will also give that user rw access to /var/named.conf and the zone files in /var/named/master, because bind-admins have rw permissions on those folders. How can I grant both junior admins and senior admins alike access to /usr/sbin/rndc and /etc/rc.d/init.d.named, while allowing only senior admins access to /var/named?


I agree with you that the rock-paper-scissors scenario in my previous post was somewhat mind-bending, and I apologize for that - although it does illustrate nicely how mixed up these permissions issues seem to me! It baffles me that I seem to have used Linux systems at work - and at home! - for quite a while, and never had to have run-ins with this area before. I'm also sure that you're right, and that the seeming pottyness of Linux permissions relates to gaps in my knowledge, rather than inherent problems with the OS. I remain a Linux fan, I'm just confused about this aspect of its operation.

I don't know if this will help you at all, but your description of permissions is a little bit off. You are correct that each file (or system resource, if you want to call it that) has owner, group, and other permissions. The group, though is not the "owner's" group. The owner can be a member of many groups. This wouldn't make sense having the file belong to the "owner's group". It may be confusing that groups and owners/users can share the same name. For instance, you have a user named "root" and a group named "root". You'll see a lot of files belong to both the owner "root" and the group "root". THey could just as easily be owned by the user "root" and the group "users".

Hope that makes sense.

Good luck,

Shilo

make a group bind-minors, add the one fellow and the bind-admins
to it, and chgrp the files the minor needs to the minor group ;)




Cheers,
Tink

Hmm. This is helping a bit, but I'm still struggling to grasp the mindset. Okay...Can I add the bind-admins group to the proposed bind-minors group as a whole, or only one by one?

And if I want to give bind-admins rw- permissions on named.conf, bind-minors r-- permission only, and any other user on the system no permissions even to read named.conf - is this possible? This seems a fairly reasonable security requirement; the admins need to be able to make changes, the minors should be able to read the file to check to ensure there isn't a syntax gaffe or the like, but because the file contains the secure RNDC key, any other users on the system should not have access.

Another issue -
I changed the group ownership of the /var/named/master directory, recursively, then assigned group permissions to rw-:

[root@dauth1 master]# chgrp -vR bind-admins /var/named/master
[root@dauth1 master]# chmod -vR 660 master >output
[root@dauth1 master]# cd ..
[root@dauth1 named]# ls -l |grep master
drw-rw---- 7 root bind-admins 12288 Jul 28 16:35 master

Logged in as root, I can, obviously, view anything I want. Logged in as a regular user, if I try to cd to /var/named/master, I get this:

[simon@dauth1 named]$ groups
simon
[simon@dauth1 named]$ cd /var/named/master
bash: cd: /var/named/master: Permission denied

All well and good.

However, I have three users in the group bind-admins, but none of them can view or list, let alone write to, files in and under the /var/named/master directory:

[hostmaster@dauth1 named]$ groups
bind-admins
[hostmaster@dauth1 named]$ cd /var/named/master
bash: cd: /var/named/master: Permission denied

Any ideas? I've checked the contents of the directories; the group ownership change has propagated down into the files and directories, and the directory itself has the right permissions, as you can see. Logged in to any user in the bind-admins group, however, I can't do what the permissions explicitly tell me I should be able to do:

[root@dauth1 named]# ls -l |grep master
drw-rw---- 7 root bind-admins 12288 Jul 28 16:35 master
[root@dauth1 named]# su hostmaster
[hostmaster@dauth1 named]$ groups
bind-admins
[hostmaster@dauth1 named]$ cd /var/named/master
bash: cd: /var/named/master: Permission denied

On suggestion of a colleague, I've tried opening the directory up entirely, then locking it down:

[root@dauth1 named]# chmod -R 777 /var/named/master
[root@dauth1 named]# ls -l |grep master
drwxrwxrwx 7 root bind-admins 12288 Jul 28 16:35 master
[root@dauth1 named]# su shawn
[shawn@dauth1 named]$ cd /var/named/master
[shawn@dauth1 master]$ exit
exit
[root@dauth1 named]# chmod -R 660 /var/named/master
[root@dauth1 named]# ls -l |grep master
drw-rw---- 7 root bind-admins 12288 Jul 28 16:35 master
[root@dauth1 named]# su shawn
[shawn@dauth1 named]$ groups
named bind-admins
[shawn@dauth1 named]$ cd /var/named/master
bash: cd: /var/named/master: Permission denied
[shawn@dauth1 named]$

Doesn't work either.

That's because to be able to cd into a directory
you need to have execute permissions on it...
so your recursive chmod caused some havoc in
this case ...

What you want is to use
find /var/named -type d -exec chmod g+x {} \;


Cheers,
Tink

Aha - you're absolutely right, that fixed it. I didn't realize that you needed to be have x permissions to even cd into a directory, although that is a potentially usefull weapon for future note.

You can sense the inevitable question here, then.

Suppose I want to give bind-minors permission to read and write to the zone files in /var/named/master, but I don't want them to be able to execute files in that directory - how can this be achieved? In order for them to be able to read files from the directory, they have to be able to cd to the directory, and to cd to the directory, as I now understand, the users require execute permissions for that directory. If the directory was static, I could probably run chmod on all the files within the directory, but what happens as files are added? Surely, they'll inherit the directory permissions and have x permissions?

Also, any thoughts on my previous question about giving bind-admins rw- permissions on named.conf, bind-minors r-- permission only, and any other user on the system no permissions even to read named.conf - is this possible?

I continue to appreciate the sage guidance.

Almost, but not quite :)
If the person who wants to change the file knows the
fully qualified name of the file he can read/write it without
having the permission to "execute" the directory. This
has the positive side-effect that you can e.g. make
backup-copies of the files that he won't see ... furthermore
you can even take the write permissions on the directory
away which e.g. will then allow that user to MODIFY a
file he has write-permissions to, but not delete it :)



Nope, they don't. Files basically get their permissions a)
via the umask during creation or b) manually via chmod


To achieve that you'll have to make use of
/etc/sudoers, I'm afraid ... have a read in
man sudo and man sudoers for that ...


Cheers,
Tink

Okay, thanks for the guidance - I'll look into SUDO as well.

Try using getfacl and setfacl. You use these to set permissions specific to a user or group for a file or directory. Get more info via man getfacl and man setfacl

Hope this helps