Share permissions and groups¶

Exercise share-permissions-and-groups-annex.pdf · PDF

Yesterday everybody at Tramuntana opened the same drawer. Now Aina keeps the salaries there. Pau, the intern, is curious. What stops him from opening the file?

Nothing, yet. A file server that gives everything to everybody is only half a file server. This page turns a simple sentence from the company, "each department writes in its own folder, nobody else gets in, and administration can read development", into real shares and real permissions. And you will discover a rule that decides every access to every network folder you will ever configure.

Two doors, both must say yes¶

Remember the four doors from the Samba file server page: the building, reception, the drawer, the paper. Today we work on the last two.

Share permissions say who may use a share and how; file-system permissions say what each user may do with each file. You pass both, one after the other.

flowchart LR
    U["<b>marta</b><br>wants to write<br>in dev"] --> S{"<b>Door 3 · the drawer</b><br>smb.conf says?"}
    S -->|"no"| X1["refused:<br>tree connect failed"]
    S -->|"yes"| F{"<b>Door 4 · the paper</b><br>rwx and ACL say?"}
    F -->|"no"| X2["refused:<br>opening remote file"]
    F -->|"yes"| OK["<b>she writes</b>"]

If one door says read and the other says write, you can read. The stricter door always wins. Keep that in mind; you will prove it with two experiments at the end.

The share words¶

Careful with the @: valid users = dev means a user called dev, not the group.

The table comes first¶

What the company asked for, written as a table. RW = read and write, R = read, – = no access.

Why can Aina read dev? She prepares the invoices and must see which projects exist, but she must not change code. That is least privilege again: this table is the security policy of the server, written before anybody touches a file.

Notice that every permission goes to a group. When Tramuntana hires Laia, a second designer, you add her to design (plus passwd and smbpasswd -a) and change nothing in smb.conf.

Three department shares¶

On the server, one folder per department, owned by its group:

for d in dev design admin; do
  sudo mkdir -p /srv/samba/$d
  sudo chgrp $d /srv/samba/$d
  sudo chmod 2770 /srv/samba/$d
done
sudo smbpasswd -a pau
sudo smbpasswd -a aina

2770 means: owner and group get rwx, others get nothing, and the 2 is setgid on a directory (Unit 5): every new file inside belongs to the folder's group, not to the creator's main group.

Then the sections in smb.conf (the first, simplest version):

[dev]
   path = /srv/samba/dev
   valid users = @dev
   read only = no

[design]
   path = /srv/samba/design
   valid users = @design
   read only = no
   create mask = 0660
   directory mask = 2770

[admin]
   path = /srv/samba/admin
   valid users = @admin
   read only = no
   browseable = no
   create mask = 0660
   directory mask = 2770

testparm -s, sudo systemctl restart smbd, and test every user against every share from deb-lab:

smbclient //ubu-srv/design -U joan -c 'put hello.txt joan.txt; ls'
smbclient -L //ubu-srv -U marta

The trap: Pau cannot edit Marta's file¶

As Marta, put plan.txt in dev. As Pau, try to replace it: refused. Both are in dev, both passed both doors. Why? Look at the file on the server:

ls -l /srv/samba/dev

The file belongs to marta, group dev, with permissions rwxr--r--: the group can only read. When you say nothing, Samba creates files with create mask = 0744: write for the owner only.

A create mask is the set of permissions Samba allows on new files; a directory mask is the same for new folders.

What a shared folder needs:

With the masks added to [dev] and smbd restarted, new files arrive like this:

-rw-rw---- marta:dev /srv/samba/dev/plan.txt
drwxrws--- marta:dev /srv/samba/dev/sprint1

A second group, read-only: the ACL¶

Aina must read dev. But a folder has one group owner, and it is dev. To give a second group different rights you need an ACL (access control list, Unit 5): an extra list of permissions on the file, beyond owner, group and others.

sudo setfacl -m g:admin:rx /srv/samba/dev
sudo setfacl -d -m g:admin:rx /srv/samba/dev
getfacl -p /srv/samba/dev

The first line gives admin read access to the folder; the second (-d, default) makes every new file inside inherit it. Forget -d and Aina can list the folder but not read the new files.

And at door 3, the final [dev] section: admin may enter, the share is read-only, and only dev is in the write list.

[dev]
   comment = Development department
   path = /srv/samba/dev
   valid users = @dev @admin
   read only = yes
   write list = @dev
   create mask = 0660
   directory mask = 2770

$ smbclient //ubu-srv/dev -U aina -c 'get plan.txt; put hello.txt aina.txt'
getting file \plan.txt of size 19 as plan.txt (18.6 KiloBytes/sec) (average 18.6 KiloBytes/sec)
NT_STATUS_ACCESS_DENIED opening remote file \aina.txt

Aina reads but cannot write: exactly the R in the table. Marta and Pau can still write.

Which door wins? Two experiments¶

Write your prediction before you try each one.

If you may only close one door, close the file system: it also protects the folder from somebody who enters by SSH. Good practice is both: the share says who comes in, the file system says what they do.

From Windows the rule is the same: as Aina, \\192.168.122.10\dev opens and shows the files, and creating one gives an access-denied window. As Marta (after net use * /delete) it works.

Key takeaways¶

• Every network access passes two doors: share permissions in smb.conf and file-system permissions on the folder. The stricter one wins.
• Write the "who may do what" table first; give permissions to groups, never to people.
• valid users decides who enters, read only + write list who writes; browseable = no only hides.
• A department folder needs a group owner, setgid (chmod 2770) and create mask = 0660 / directory mask = 2770. Masks act on new files only.
• A second group with different rights needs an ACL: setfacl -m plus -d for new files.

Quick check¶

Samba asked each user for a password. The next protocol asks nothing: it trusts the client machine. Why would anybody want that? Find out in NFS.