File security on Niflheim

Overview

According to DTU’s IT security policies Appendix B, home directories are personal and private. Access to another user’s home directory requires explicit agreement, even if file permissions allow it.

We recommend the GROUP model for a balance between security and ease of collaboration. Each research section should choose a model appropriate to its data, with the section leader responsible for the decision.

Please contact the Niflheim support if you would like further advice.

Choose a security model

Model	Who may access your home directory
OPEN	All Niflheim users (current default; not recommended).
GROUP	You and members of your home directory’s Unix group (recommended).
PRIVATE	You only, apart from administrators with privileged access.

Apart from the home folder, access to a file requires permission on the file itself and traversal permission on every parent folder. You can restrict individual folders or grant access to specific folders using Access Control Lists (ACLs).

Faculty belong to the group xxxfac, postdocs and Ph.D. students to xxxvip, and M.Sc. / B.Sc. students to xxxstud where xxx is the research section abbreviation. Under the GROUP or PRIVATE models, students and supervisors can easily grant each other access to selected folders using ACLs. Run id to see your user ID and group memberships.

Warning

Encrypt any files containing real secrets! If somebody gains root access to a computer that can mount Niflheim folders, they can access all your files!

To Do: Provide examples on how to encrypt folders.

Technical details

We recommend contacting Niflheim support to set data access up as you desire. Below is the do-it-yourself description.

Permission basics

Standard Unix permissions apply to the owner (u for user), owning group (g for group), and everyone else (o for other):

Permission	Files	Folders
Read (`r`)	Read contents	List names
Write (`w`)	Modify contents	Create, delete or rename entries (also requires `x`)
Execute (`x`)	Run as a program	Traverse the folder to access entries

Access to a file requires permission on the file itself and x on every parent folder. Use chmod to change standard permissions; inspect them with ls -l file or ls -ld folder.

Access control lists (ACLs) grant permissions to additional users or groups without changing group ownership. Use setfacl to change ACLs and getfacl to inspect them. You can set a default ACL on a folder, then newly created files and subfolders inherit those permissions.

For introductions, see Unix file permissions and Managing file access with ACLs.

Implementing a model by setting home-folder permissions

The model is implemented by setting permissions on your home folder; permissions on its contents remain unchanged.

Run one of these commands:

chmod og=rx "$HOME"     # OPEN: allow all users
chmod g=rx,o= "$HOME"   # GROUP: allow the owning group
chmod og= "$HOME"       # PRIVATE: allow only yourself

These commands leave your own permissions unchanged. Run getfacl "$HOME" to check the result. To share selected subfolders under GROUP or PRIVATE, follow the sharing recipe below.

Closing specific folders in the OPEN or GROUP models

You can always close off a folder so it is either private-only, or only accessible to your group. You do that by:

chmod g=rx,o= folder  # Only the group can read/list the folder
chmod og= folder      # Only the owner can access the folder

Check with getfacl folder if any named user or group still has access through an ACL. If so remove the ACL with setfacl -x u:username folder or setfacl -x g:groupname folder.

Checking access to a specific folder

Use getfacl folder to check who has access. Example:

~$ getfacl tmp
# file: tmp
# owner: schiotz
# group: camdfac
user::rwx
group::r-x                # <--- The group camdfac has r-x access (Unix permissions)
group:camdvip:r-x         # <--- The group camdvip also has access (through the ACL)
mask::r-x
other::---

Note that this folder named tmp belongs to the group camdfac which has access, but the group camdvip has also been given access.

Giving students access in the GROUP or PRIVATE models

To share $HOME/shared with a student, replace username below with their login name. The folder must already exist. Students can use the same recipe to share with supervisors. You can also give access to an entire group by replacing u:username with g:groupname.

Warning

Traversing your home folder lets the recipient check guessed names and some metadata, even without listing its contents. An AI can make very qualified guesses about file names!

If this is unacceptable, use of a shared storage space outside your home folder is necessary. Contact Niflheim support in this case.

Before sharing, review access to your other files. To remove access through the “others” permissions from all immediate files and folders, including hidden entries but excluding symbolic links:

find "$HOME" -mindepth 1 -maxdepth 1 ! -type l -exec chmod o= {} +

This leaves group permissions and existing ACL grants unchanged. Make sure that any new files/folders created (without a default ACL) are also locked down by adding a umask line to your ~/.bashrc file and run it in your current shell:

umask 0027
# or using symbolic notation:
umask u=rwx,g=rx,o=

This allows group access but no access for others.

Before adding access, inspect existing ACLs with getfacl "$HOME" and getfacl -R "$HOME/shared". If you find unexpected ACL entries, contact Niflheim support before proceeding, otherwise you might accidentally grant more access than you intended!

Give the student traversal access to your home folder, then read access to the shared folder and its contents:

setfacl -m u:username:x "$HOME"              # Traverse without listing names
setfacl -R -m u:username:rX "$HOME/shared"   # Access existing contents
setfacl -R -m d:u:username:rX "$HOME/shared" # Inherit access for new contents

-R applies recursively; X grants execute access to directories and files already executable by anyone. The d: prefix sets default ACLs on all existing directories. New entries inherit access, limited by the permissions requested by the creating application. Group ownership stays unchanged.

Check the result:

getfacl "$HOME" "$HOME/shared"

Give the student the full path to the shared folder and ask them to check that they can read its files. For nested shared folders, they also need x on every intermediate folder.

If getfacl shows user:username:r-x #effective:r--, the ACL mask is blocking execute access. Changing group permissions with chmod changes this mask and can affect the student’s access.

Moving or copying files into the shared folder: default ACLs apply when entries are created, but if you move exitisting folders or files into the shared folder they keep their original permissions:

mv preserves existing permissions and ACLs, so moved files and folders do not inherit the shared folder’s access settings.
Plain cp normally lets newly created entries inherit the destination’s default ACL, limited by the source permissions. However, cp -p and cp -a preserve source permissions and ACLs instead, so the student may lose access to the copied files.
rsync -a preserves source permission bits, which can limit the student’s access through the ACL mask. It does not copy source ACLs unless you also use -A (--acls); that option replaces destination ACLs with source ACLs.

After moving files with mv or copying with preserved permissions or ACLs, rerun both recursive setfacl commands above to grant access to the imported files and set inheritance on imported folders. Ask the student to check access again after the transfer.