PAM
in [Slackware]
|
Prev: Error in script execution
Next: Kmail and LDAP support
From: +Alan Hicks+ on 14 Mar 2006 13:46 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In alt.os.linux.slackware, Keith Keller dared to utter, > Consider one possible example: two groups exist, groupa and groupb, and > you wish to grant all members of both groups write access to > /home/groupab. With the traditional model, you need to create a new > group, groupab, and manually add all members of groupa and groupb to > group groupab. Then, when groupa changes, you also need to update > groupab. With ACLs, it's easy: grant write to groupa and to groupb > separately: no separate group or group maintenance is needed. And this > is a fairly trivial example; I'm sure there are other more complex > examples where ACLs would be easy and ugo difficult. Indeed. Consider the following example. We have ten users: USER{0-9} and three groups: GROUP{0-2} GROUP0: USER0, USER1 GROUP1: USER2, USER3, USER4, USER5 GROUP2: USER 6, USER7, USER8, USER9 GROUP0 is our fictional network's supervisors. Groups GROUP{1,2} are workers supervised by user USER{0,1} respectively. Suppose we have two samba shared directories: /data/group1 and /data/group2. We want to keep GROUP2 from reading and writing to /data/group1 and vice-versa. However, we want GROUP0 to be able to read files in both directories. Using traditional UNIX filesystem permissions, we can do the following. drwxrwx--- 2 root GROUP1 48 2006-03-14 13:34 group1/ drwxrwx--- 2 root GROUP2 48 2006-03-14 13:34 group2/ This will allow GROUP1 and GROUP2 to read and write to their respective directories, but won't allow either to read or write the other's directory. Unfortunately, GROUP0 is left out in the cold. We could change the permissions, which would allow GROUP0 in like so: drwxrwxr-x 2 root GROUP1 48 2006-03-14 13:34 group1/ drwxrwxr-x 2 root GROUP2 48 2006-03-14 13:34 group2/ Unfortunately, that allows GROUP1 to read files in group2/ and vice-versa. Additionally, anyone on the system can read these files. As Keith mentioned, the obvious answer is to add the supervisor users to their individual groups like so: GROUP1: USER0, USER2, USER3, USER4, USER5 GROUP2: USER1, USER6, USER7, USER8, USER9 But, what if I want USER0 to be able to read files in group2/, but not write to the directory? That leaves me with the rather embarrasing situation of: dr-xrwx--- 2 USER1 GROUP1 48 2006-03-14 13:34 group1/ dr-xrwx--- 2 USER0 GROUP2 48 2006-03-14 13:34 group2/ Congratulations. We've accomplished our goal. But wait, we just hired five more people: USERA, USERB, USERC, USERD, USERE. USERA is a supervisor and the other new users are his workers. How do we allow users 0 and A to read group2 but not write to it? This cannot be accomplished with traditional UNIX filesystem permissions. What you need is an ACL. Below is my fictional and entirely unlike real-world ACL. ACL group1 GROUP0: r-- GROUP1: rwx USER0: rwx And FWIW, real work needs to be done on ACLs, but doing so breaks POSIX, so there's a lot of inertia saying not to do it. - -- It is better to hear the rebuke of the wise, Than for a man to hear the song of fools. Ecclesiastes 7:5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQFEFw/gz8zcalmVmBkRAn41AJ9r0ak5kL0L10Z3X7twSvNcOaxvZwCbBqKJ 6Gr1KtJdZ7tVsuKqdHocpNc= =D6cD -----END PGP SIGNATURE----- |