1

Given that an app is writing files with 700 permissions, which means they are not readable by the group, I need these files to be readable by a special backup user account.

ACL seems to be completely useless since chmod modifies the mask and users other than the owner or other groups still have no permissions.

  1. Periodically doing recursive chmod? Hakish and resource waste, especially on very large file sets.
  2. Using root for this (via sudo)? Not secure. No fine-grained control. Not appropriate for rsync initiated on remote machine, for example NAS.
  3. Using same user as the app making those files, i.e. using owner user for backups. Still hakish and not desired since backup user should have only read access and only for given directories.. Especially important for rsync initiated from outside.
  4. Mounting given directory to another directory using something like bindfs? Performance hit is significant and not justified for such simple permission-related task.

I wonder why linux doesn't allow administrators dictate applications minimal allowed permission on files (The maximum permissions can be limited using a mask, but it cannot be enforced or transparently added, which seems weird)

Any solutions?

1
  • rrsync is a script to enforce restricted rsync. It relies on the possibility in ssh to set an authorized key to a specific set of commands only. Link. || Alternatively - maybe use a samba-share locally and lock it down as far as possive incl. read-only and localhost (or backup server IP) as client source.
    – FelixJN
    Commented Jun 26, 2023 at 7:34

1 Answer 1

0

In a similar situation I've taken the chmod approach, but managed through a loop started at boot time and driven by inotifywait. This is a cut-down version of the code I actually use, which also handles ownership/groupship, and logs all changes or errors:

#!/bin/bash
inotifywait --monitor --recursive --event create,attrib --format '%w%f' "$@" |
    while IFS= read -r item
    do
        # Avoid looping when we apply the fix-up chmod
        perm=$(stat -c %A "$item")

        if [[ -d "$item" ]] && [[ ! "$perm" =~ dr.xr.xr-x ]]
        then
            # Directory with wrong permissions
            printf 'dir\t%s\n' "$item"
            chmod ug+rx,o=rx "$item"
        fi
        if [[ ! -d "$item" ]] && [[ ! "$perm" =~ -r..r..r.. ]]
        then
            # Item (not a directory) with wrong permissions
            printf 'other\t%s\n' "$item"
            chmod ug+rw,o-w,o+r "$item"
        fi
    done

Although you get the hackishness of chmod and the code's inability to handle filenames containing newlines, this is moderated by a tool that only fires when a file is created or its attributes modified. Acceptable for large sane datasets.

You would probably want to supplement this with an occasional process that fixed up all permissions unconditionally. This example ensures user/group permissions have a minimum of read (and execute if a directory), and others' permissions are the same but without write:

find /path/to/base -type d -exec chmod ug+rx,o=rx {} \; -o -exec chmod ug+rw,o-w,o+r {} \;

If I were writing the solution today I'd probably consider incron rather than the loop

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .