Advanced Unix Groups

Imagine we want to have some files, where one group of users can read and write to them them, while another group of users can only read them. How do we achieve this using basic Unix permissions?

This is harder than I first thought it would be. This is what I tried:

> sudo su useradd writeuser useradd readuser groupadd readgroup groupadd writegroup gpasswd -a readuser readgroup gpasswd -a writeuser writegroup

Add the users to /etc/group:

> readgroup:x:1001:readuser,writeuser writegroup:x:1002:writeuser

Now lets try to setup the directory.

> mkdir testdir chown root:readgroup testdir chmod a-rwx,g-w+rx,u+rwx testdir su writeuser cd testdir echo "Should we be able to write to it?" > hello.txt

I think this is just because Unix permissions just do not allow this level of complexity.

Discuss this post - leave a comment

9 thoughts on “Advanced Unix Groups

  1. <p>You'll be wanting <a class="reference external" href="http://acl.bestbits.at/">Access Control Lists</a> then. <img src="/static/forum/img/smilies/smile.png"></p>

  2. <p>....err...what Paul said, only here's an <a class="reference external" href="http://www.enterprisenetworkingplanet.com/netsysm/article.php/3077971">article</a> on their usage. It's a
    bit dated, but I think it's still accurate.</p>

  3. <p>I think you want to do</p>
    <p>chown writeuser:readgroup testdir</p>
    <p>don't you?</p>
    <p>Or it is much simpler if it can be world readable:</p>
    <p>chmod a-w+rx,g+rwx,u+rwx testdir</p>
    <p>And I believe selinux implements ACLs, so any distro that support selinux
    would do that.</p>

  4. <p>Also a bit dated, <a class="reference external" href="http://www.suse.de/~agruen/acl/linux-acls/online/">here is a document on POSIX Access Control Lists on
    Linux</a>, which is rather informative.</p>

  5. <p>You'll probably also want to set a proper umask for anyone in the writegroup
    group if you're dead set on using basic file permissions.</p>
    <p>Like the other guys said though, ACLs are really the way to go for this.</p>

  6. <p>Mish, sadly, the idea was to make the directory not readable to everyone,
    only to those in the two groups.</p>
    <p>Setting it to writeuser:readgroup doesn't help as writeuser was just an
    example of a possible user in the writegroup.</p>
    <p>For the rest of you, thanks for your comments, but I said &quot;<em>How do we achieve
    this using basic Unix permissions?</em>&quot;, I knew about ACLs but they look
    horrible and I wanted to work out if it is possible with just Unix
    permissions.</p>

  7. <p>Have you tried hard-links?Â&nbsp; You are probably familiar with symlinks aka
    soft-links.Â&nbsp; Hard-links have an additional restriction in that they must be
    on the same filesystem, but the ownership and permissions are assigned to the
    link, not the data it points to, so it's possible to point multiple hard
    links each with its own set of permissions at the same on-disk data.</p>
    <p>Simplest both for users and to administer is probably to create two
    directories, say readdir and writedir, setting their group and permissions
    appropriately.Â&nbsp; Then create/copy/move the files into writedir, and hard-link
    (using the ln command, without the -s switch you've likely become used to
    using) them into readdir as well, again setting the groups and permissions
    appropriately.</p>
    <p>While just that much will suffice if the same set of files are reused over
    time, if your usage involves dynamic file creation and deletion, keep in mind
    that both links must be dealt with.Â&nbsp; (Conceptually, editing an existing file
    edits the file itself, while creating or deleting one edits the directory
    entry, that is, the link, for the file.Â&nbsp; Thus, since each link is separate,
    editing them is two separate directory edit operations.Â&nbsp; That's good since
    it's actually the feature we are using to get the different permissions.)Â
    If creating/deleting the files is routine, consider automating the task with
    a script (or code it directly into the application if that's what you are
    doing) that manages both links with a single command.Â&nbsp; Of course, if it's a
    preexisting binary doing the creation/deletion directly, and you don't have
    source or modify rights to that binary, that may be easier said than done,
    but that's what free/libre and open source software is all about. =8^)</p>
    <p>See, no ACLs necessary after all!</p>
    <p>Duncan</p>

  8. <p>Duncan, sadly the permissions are stored with the data (inode), not with the directory entries (hard-links). Zeth needs ACLs -- no way to do this with basic unix permissions.</p>

  9. <p>OpenSuSe and SLED / SLES support advanced ACL's.</p>
    <p>It allows for multiple groups and users all to have different rights</p>
    <p>man setfacl and getfacl</p>

How about Global Thermonuclear War? Wouldn't you prefer a good game of chess? Powered by zpress