Shared directory on a Linux machine, v2

    In a situation where there is a shared directory on the server with several users (for example, on a file-wipe on the local network), you may face a problem when you need to give read and write permissions to all registered users. The situation has already been discussed on Habré, so I will allow myself to literally quote an article by karapuz user :

    What can be done here? Several solutions immediately come to mind:

    1. Install the corresponding umask for the shared directory;
    2. Set the appropriate default acl;
    3. Set the SGID bit.

    Well, they applied one of the solutions, or all at once. Everything seems to work. Both users have full access to the entire contents of the shared directory, the new files in this directory inherit its rights, but now you have thrown off photos from the camera into this directory. Your wife enters the system under her user and decides to change these photos a little, only when saving a message appears about insufficient rights. It turns out the files you copied did not inherit the rights of the shared directory. Why? Yes, because the cp utility doesn’t care about your umask and acl. It copies files while retaining the original rights, or the rights are reduced, it all depends on the rights to the directory where we are copying.


    As a solution to the problem, karapuz suggested using one of the two fam or gamin file system monitoring daemons and the fileschanged utility .

    But, as practice has shown, both of these daemons significantly load the server, especially when users are actively working with files in a controlled directory. On the network, you can find user complaints that gamin consumes up to 30% of the processor time. I can say that I got the same disappointing results. To ease the load on the piece of iron, I decided to use the inotifywait utility from the inotify-tools package : inotifywait instead of the mentioned utilities

    sudo apt-get install inotify-tools

    cleverly tracks changes to directories and files using the inotify interface.

    And so, we have a program for monitoring state changes, now we need to feed it the necessary directory and force it to do it after a reboot.

    Here is a sample solution on my server. Let's say you need to monitor the rights in the directory / home / sharez /

    Create a launcher /usr/local/bin/inotifywait.sh A close look will notice that the rights and ownership of directories are set recursively. Why is this done, because any recursive actions are additional significant overhead? The fact is that inotifywait monitors only the inode of a file or directory. And if when copying the directory create events

    sudo nano /usr/local/bin/inotifywait.sh

    #!/bin/sh
    # Передаю директорию в качестве аргумента
    inotifywait -mrq -e close_write -e moved_to -e create --format "%w%f" "$1" | while read "FILE"
    do
    if [ -d "$FILE" ]; then
    chown -R nobody:nogroup "$FILE"
    chmod -R a+rwX "$FILE"
    elif [ -f "$FILE" ]; then
    chown nobody:nogroup "$FILE"
    chmod a+rw-x "$FILE"
    fi
    done
    :


    affects all files and subdirectories, then when moving within the same physical partition, the moved_to event only affects the directory being moved (knows about the operation with the directory inode, but the inodes inside it remain untouched) and does not affect the subdirectories and files in it. As a result, when performing the move operation, we may lose the most important thing, because of which we started all this - inheritance of rights. Therefore, I decided to sacrifice performance, especially since the operation of moving a large number of files at the same time is rarely performed.
    Now you need to create a script for init.d

    I did not like the startup options from rc.local , so the inotifywait.sh startup script in init.dit will look something like this: We make our scripts executable: Add the boot script to the runlevels and run: It seems that everything, the wild performance sag that I periodically caught, when a bunch of people worked with their files on the server, disappeared. At the same time, I solved one side problem: as you can see, in addition to the access rights in the script, I also appoint the owner and group. In reality, several such scripts manage document flow in the office on the same binary rights, without resorting to acl. A document goes a certain way department by department, and at any given time only one department has the right to edit (or even read). UPD: changed the name a little, now it is less consistent with the original karapuz article

    sudo nano /etc/init.d/inotifywait.sh

    #! /bin/sh
    case "$1" in
    start|"")
    rm -f /tmp/inotifywait.log
    /usr/local/bin/inotifywait.sh /home/sharez/ >/tmp/inotifywait.log 2>&1 &
    ;;
    restart|reload|force-reload)
    echo "Error: argument '$1' not supported" >&2
    exit 3
    ;;
    stop)
    # Надо сделать так, чтобы я убивал только свои inotifywait
    ;;
    *)
    echo "Usage: inotifywait.sh [start|stop]" >&2
    exit 3
    ;;
    esac
    :



    sudo chmod a+x /usr/local/bin/
    sudo chmod a+x /etc/init.d/inotifywait.sh



    sudo update-rc.d inotifywait.sh defaults
    sudo service inotifywait.sh start






    but, rather, in fact.

    Also popular now: