Разрешить пользователям изменять принадлежность файла к определенному файлу без sudo

Question 1

Предположим, что у нас есть такая ситуация:

-rwxrwx-r- 1 user1 mygroup  0 Sep 12 16:53 testfile

Группа разработчиков работает на той же VM (Linux). Мне нужно смоделировать концепцию checkout / checkin. Если пользователь проверяет файл, никто не сможет его записать, пока он не проверит его.

Я попытался изменить владельца файла; каждый раз, когда пользователь хочет проверить, он становится владельцем файла и не позволяет другим записывать на него, а затем проверяет, изменив владельца файла на значение по умолчанию и устанавливает права доступа к файлу по умолчанию. Это означает, что мне понадобятся chown и chmod, но для этих команд требуется sudo, и я не могу дать sudo разрешения разработчикам.

Могу ли я дать пользователю возможность chown и chmod только определенный файл?

Question 2

Вам придется написать скрипт, который проверяет условия, а затем предоставить вашим пользователям sudo доступ только к этому сценарию. Что-то вроде:

#! /bin/bash
set -e
die()
{
    printf "%s\n" "$@"
    exit 1
}

if [[ $EUID != 0 ]]
then
    die "This script must be run with sudo."
fi

DEFAULT_USER=nobody
SOURCE_DIR=/some/dir

cd "$SOURCE_DIR"

# Get path of file relative to the source directory
# Then we can check if it is actually in the directory.
FILE=$(realpath -e --relative-base="$SOURCE_DIR" "${1?}")    
if [[ $FILE == /* ]]
then
    die "$1 is outside $SOURCE_DIR."
fi

FILE_OWNER=$(stat -c %U "$FILE")

case $FILE_OWNER in
    $DEFAULT_USER)
        # checkout
        echo "Checking out $FILE..."
        chown "$SUDO_USER" "$FILE"
        ;;
    $SUDO_USER)
        # checkin
        echo "Checking in $FILE..."
        chown nobody "$FILE"
        ;;
    *)
        die "Sorry, this file is checked out by $FILE_OWNER."
        ;;
esac

Сохраните это как, скажем, /usr/local/bin/check, добавьте следующее правило sudoers:

%dev ALL = (root) /usr/local/bin/check

Это предполагается:

[d4 ] Все разработчики находятся в группе dev (если нет, используйте имена пользователей или группы соответственно). Файлы находятся в /some/dir. Измените $SOURCE_DIR соответственно. Пользователем по умолчанию является nobody, а непроверенные файлы принадлежат пользователю по умолчанию. Никто не имеет прав на запись в исходный каталог, кроме root.

Затем разработчики могут выполнить:

sudo check some/file

, чтобы проверить /some/dir/some/file, и запустите его снова, чтобы проверить его.

Question 3

Question 4

Вам придется написать скрипт, который проверяет условия, а затем предоставить вашим пользователям sudo доступ только к этому сценарию. Что-то вроде:

#! /bin/bash
set -e
die()
{
    printf "%s\n" "$@"
    exit 1
}

if [[ $EUID != 0 ]]
then
    die "This script must be run with sudo."
fi

DEFAULT_USER=nobody
SOURCE_DIR=/some/dir

cd "$SOURCE_DIR"

# Get path of file relative to the source directory
# Then we can check if it is actually in the directory.
FILE=$(realpath -e --relative-base="$SOURCE_DIR" "${1?}")    
if [[ $FILE == /* ]]
then
    die "$1 is outside $SOURCE_DIR."
fi

FILE_OWNER=$(stat -c %U "$FILE")

case $FILE_OWNER in
    $DEFAULT_USER)
        # checkout
        echo "Checking out $FILE..."
        chown "$SUDO_USER" "$FILE"
        ;;
    $SUDO_USER)
        # checkin
        echo "Checking in $FILE..."
        chown nobody "$FILE"
        ;;
    *)
        die "Sorry, this file is checked out by $FILE_OWNER."
        ;;
esac

Сохраните это как, скажем, /usr/local/bin/check, добавьте следующее правило sudoers:

%dev ALL = (root) /usr/local/bin/check

Это предполагается:

Все разработчики находятся в группе dev (если нет, используйте имена пользователей или группы соответственно). Файлы находятся в /some/dir. Измените $SOURCE_DIR соответственно. Пользователем по умолчанию является nobody, а непроверенные файлы принадлежат пользователю по умолчанию. Никто не имеет прав на запись в исходный каталог, кроме root.

Затем разработчики могут выполнить:

sudo check some/file

, чтобы проверить /some/dir/some/file, и запустите его снова, чтобы проверить его.

Question 5

Вам придется написать скрипт, который проверяет условия, а затем предоставить вашим пользователям sudo доступ только к этому сценарию. Что-то вроде:

#! /bin/bash
set -e
die()
{
    printf "%s\n" "$@"
    exit 1
}

if [[ $EUID != 0 ]]
then
    die "This script must be run with sudo."
fi

DEFAULT_USER=nobody
SOURCE_DIR=/some/dir

cd "$SOURCE_DIR"

# Get path of file relative to the source directory
# Then we can check if it is actually in the directory.
FILE=$(realpath -e --relative-base="$SOURCE_DIR" "${1?}")    
if [[ $FILE == /* ]]
then
    die "$1 is outside $SOURCE_DIR."
fi

FILE_OWNER=$(stat -c %U "$FILE")

case $FILE_OWNER in
    $DEFAULT_USER)
        # checkout
        echo "Checking out $FILE..."
        chown "$SUDO_USER" "$FILE"
        ;;
    $SUDO_USER)
        # checkin
        echo "Checking in $FILE..."
        chown nobody "$FILE"
        ;;
    *)
        die "Sorry, this file is checked out by $FILE_OWNER."
        ;;
esac

Сохраните это как, скажем, /usr/local/bin/check, добавьте следующее правило sudoers:

%dev ALL = (root) /usr/local/bin/check

Это предполагается:

Все разработчики находятся в группе dev (если нет, используйте имена пользователей или группы соответственно). Файлы находятся в /some/dir. Измените $SOURCE_DIR соответственно. Пользователем по умолчанию является nobody, а непроверенные файлы принадлежат пользователю по умолчанию. Никто не имеет прав на запись в исходный каталог, кроме root.

Затем разработчики могут выполнить:

sudo check some/file

, чтобы проверить /some/dir/some/file, и запустите его снова, чтобы проверить его.

Question 6

Вы можете сделать это, хотя я думаю, что, возможно, более практичное решение, разработанное для такого сотрудничества.

В любом случае, вот что делать:

Создайте группу, добавьте пользователей в группу и предоставить группе право на запись в родительский каталог. Затем они смогут chown и chmod сохранить файл без использования sudo

Демонстрация:

sudo addgroup devs
sudo adduser zanna devs
sudo adduser pixie devs
mkdir development
chmod g+w development 
sudo chown root:devs development 
touch development/testfile
cd development
sudo chown root:devs testfile

Это настройка. Давайте проверим это:

zanna@xubi:~/development$ chown $USER testfile
$ stat -C "%U %G" testfile
zanna devs
$ chmod 600 testfile
$ stat -c %a testfile
600
$ su pixie
[enter password...]
pixie@xubi:/home/zanna/development$ chown $USER testfile
$ stat -c %U testfile
pixie

и т. Д. ... но это будет работать только при условии, что люди проверяют разрешения или пытаются записать в файл до того, как они начнут работать chown и chmod, который, вероятно, не интуитивно понятен ... И если у них есть разрешение на запись в родительский каталог, они всегда смогут принудительно записать файл, хотя они должны получить предупреждение, в зависимости от используемого им редактора.

Question 7

Question 8

Если пользователь имеет возможность запускать следующую команду sudo:

sudo bash

Он сможет выполнить любую команду с правами root, включая chown в любом файле. [!d1 ]

Вы можете настроить /etc/sudoers, чтобы позволить конкретному пользователю выполнять определенные команды

, например вы можете установить следующую строку в /etc/sudoers:

user2 ALL=(ALL) NOPASSWD: /bin/chown
user2 ALL=(ALL) NOPASSWD: /bin/chmod

Примечание: если у кого-то есть возможность запускать chown и chmod в качестве root, они могут легко получить полный доступ root (например, путем редактирования /etc/passwd)

Question 9

Я согласен с тем, что sccs (Source Code Control System), включая исходную с начала 70-х, может быть хорошим решением для проверки в общих файлах, поскольку она поддерживает контроль версий, а также документацию об изменениях. [!d0 ]

Как дополнение к предложению Zanna, короткий скрипт, который проверяет, является ли пользователь владельцем, затем, если нет, проверяет, имеет ли группа разрешение на запись. Это означало бы, что он был проверен. Если он доступен, он будет chown, затем измените разрешения на 600 (файл занят). Чтобы освободить его, он изменит права доступа на 660. Таким образом, имя владельца будет указывать, кто заблокировал или кто последний заблокировал его, а групповое разрешение укажет, было ли оно доступно или все еще используется.

Question 10

Я согласен с тем, что sccs (Source Code Control System), включая исходную с начала 70-х, может быть хорошим решением для проверки в общих файлах, поскольку она поддерживает контроль версий, а также документацию об изменениях.

Как дополнение к предложению Zanna, короткий скрипт, который проверяет, является ли пользователь владельцем, затем, если нет, проверяет, имеет ли группа разрешение на запись. Это означало бы, что он был проверен. Если он доступен, он будет chown, затем измените разрешения на 600 (файл занят). Чтобы освободить его, он изменит права доступа на 660. Таким образом, имя владельца будет указывать, кто заблокировал или кто последний заблокировал его, а групповое разрешение укажет, было ли оно доступно или все еще используется.

Question 11

Если пользователь имеет возможность запускать следующую команду sudo:

sudo bash

Он сможет выполнить любую команду с правами root, включая chown в любом файле.

Вы можете настроить /etc/sudoers, чтобы позволить конкретному пользователю выполнять определенные команды

, например вы можете установить следующую строку в /etc/sudoers:

user2 ALL=(ALL) NOPASSWD: /bin/chown
user2 ALL=(ALL) NOPASSWD: /bin/chmod

Примечание: если у кого-то есть возможность запускать chown и chmod в качестве root, они могут легко получить полный доступ root (например, путем редактирования /etc/passwd)

Question 12

Я согласен с тем, что sccs (Source Code Control System), включая исходную с начала 70-х, может быть хорошим решением для проверки в общих файлах, поскольку она поддерживает контроль версий, а также документацию об изменениях.

Как дополнение к предложению Zanna, короткий скрипт, который проверяет, является ли пользователь владельцем, затем, если нет, проверяет, имеет ли группа разрешение на запись. Это означало бы, что он был проверен. Если он доступен, он будет chown, затем измените разрешения на 600 (файл занят). Чтобы освободить его, он изменит права доступа на 660. Таким образом, имя владельца будет указывать, кто заблокировал или кто последний заблокировал его, а групповое разрешение укажет, было ли оно доступно или все еще используется.

Question 13

Question 14

Если пользователь имеет возможность запускать следующую команду sudo:

sudo bash

Он сможет выполнить любую команду с правами root, включая chown в любом файле.

Вы можете настроить /etc/sudoers, чтобы позволить конкретному пользователю выполнять определенные команды

, например вы можете установить следующую строку в /etc/sudoers:

user2 ALL=(ALL) NOPASSWD: /bin/chown
user2 ALL=(ALL) NOPASSWD: /bin/chmod

Примечание: если у кого-то есть возможность запускать chown и chmod в качестве root, они могут легко получить полный доступ root (например, путем редактирования /etc/passwd)

muru · Accepted Answer · 22 May 2018 в 18:30

Вам придется написать скрипт, который проверяет условия, а затем предоставить вашим пользователям sudo доступ только к этому сценарию. Что-то вроде:

#! /bin/bash
set -e
die()
{
    printf "%s\n" "$@"
    exit 1
}

if [[ $EUID != 0 ]]
then
    die "This script must be run with sudo."
fi

DEFAULT_USER=nobody
SOURCE_DIR=/some/dir

cd "$SOURCE_DIR"

# Get path of file relative to the source directory
# Then we can check if it is actually in the directory.
FILE=$(realpath -e --relative-base="$SOURCE_DIR" "${1?}")    
if [[ $FILE == /* ]]
then
    die "$1 is outside $SOURCE_DIR."
fi

FILE_OWNER=$(stat -c %U "$FILE")

case $FILE_OWNER in
    $DEFAULT_USER)
        # checkout
        echo "Checking out $FILE..."
        chown "$SUDO_USER" "$FILE"
        ;;
    $SUDO_USER)
        # checkin
        echo "Checking in $FILE..."
        chown nobody "$FILE"
        ;;
    *)
        die "Sorry, this file is checked out by $FILE_OWNER."
        ;;
esac

Сохраните это как, скажем, /usr/local/bin/check, добавьте следующее правило sudoers:

%dev ALL = (root) /usr/local/bin/check

Это предполагается:

[d4 ] Все разработчики находятся в группе dev (если нет, используйте имена пользователей или группы соответственно). Файлы находятся в /some/dir. Измените $SOURCE_DIR соответственно. Пользователем по умолчанию является nobody, а непроверенные файлы принадлежат пользователю по умолчанию. Никто не имеет прав на запись в исходный каталог, кроме root.

Затем разработчики могут выполнить:

sudo check some/file

, чтобы проверить /some/dir/some/file, и запустите его снова, чтобы проверить его.

с% dev ALL = (root) / usr / local / bin / check я могу добавить аргумент, чтобы заставить его только выполнить файл (предотвратить запись), поэтому он не сможет изменить скрипт — ILY, 14 September 2017 в 18:28
@Ilyasse, файл должен принадлежать root, и вообще не имеет прав на запись. — muru, 14 September 2017 в 18:29
+1 в основном потому, что он элегантно написан, но кратким и отчасти потому, что мне не нужно писать ответ, чтобы я мог сосредоточиться на моем проекте ботов с магазинами: D — WinEunuuchs2Unix, 15 September 2017 в 02:01

muru · Accepted Answer · 18 July 2018 в 06:56

Вам придется написать скрипт, который проверяет условия, а затем предоставить вашим пользователям sudo доступ только к этому сценарию. Что-то вроде:

#! /bin/bash
set -e
die()
{
    printf "%s\n" "$@"
    exit 1
}

if [[ $EUID != 0 ]]
then
    die "This script must be run with sudo."
fi

DEFAULT_USER=nobody
SOURCE_DIR=/some/dir

cd "$SOURCE_DIR"

# Get path of file relative to the source directory
# Then we can check if it is actually in the directory.
FILE=$(realpath -e --relative-base="$SOURCE_DIR" "${1?}")    
if [[ $FILE == /* ]]
then
    die "$1 is outside $SOURCE_DIR."
fi

FILE_OWNER=$(stat -c %U "$FILE")

case $FILE_OWNER in
    $DEFAULT_USER)
        # checkout
        echo "Checking out $FILE..."
        chown "$SUDO_USER" "$FILE"
        ;;
    $SUDO_USER)
        # checkin
        echo "Checking in $FILE..."
        chown nobody "$FILE"
        ;;
    *)
        die "Sorry, this file is checked out by $FILE_OWNER."
        ;;
esac

Сохраните это как, скажем, /usr/local/bin/check, добавьте следующее правило sudoers:

%dev ALL = (root) /usr/local/bin/check

Это предполагается:

Все разработчики находятся в группе dev (если нет, используйте имена пользователей или группы соответственно). Файлы находятся в /some/dir. Измените $SOURCE_DIR соответственно. Пользователем по умолчанию является nobody, а непроверенные файлы принадлежат пользователю по умолчанию. Никто не имеет прав на запись в исходный каталог, кроме root.

Затем разработчики могут выполнить:

sudo check some/file

, чтобы проверить /some/dir/some/file, и запустите его снова, чтобы проверить его.

muru · Accepted Answer · 24 July 2018 в 18:42

Вам придется написать скрипт, который проверяет условия, а затем предоставить вашим пользователям sudo доступ только к этому сценарию. Что-то вроде:

#! /bin/bash
set -e
die()
{
    printf "%s\n" "$@"
    exit 1
}

if [[ $EUID != 0 ]]
then
    die "This script must be run with sudo."
fi

DEFAULT_USER=nobody
SOURCE_DIR=/some/dir

cd "$SOURCE_DIR"

# Get path of file relative to the source directory
# Then we can check if it is actually in the directory.
FILE=$(realpath -e --relative-base="$SOURCE_DIR" "${1?}")    
if [[ $FILE == /* ]]
then
    die "$1 is outside $SOURCE_DIR."
fi

FILE_OWNER=$(stat -c %U "$FILE")

case $FILE_OWNER in
    $DEFAULT_USER)
        # checkout
        echo "Checking out $FILE..."
        chown "$SUDO_USER" "$FILE"
        ;;
    $SUDO_USER)
        # checkin
        echo "Checking in $FILE..."
        chown nobody "$FILE"
        ;;
    *)
        die "Sorry, this file is checked out by $FILE_OWNER."
        ;;
esac

Сохраните это как, скажем, /usr/local/bin/check, добавьте следующее правило sudoers:

%dev ALL = (root) /usr/local/bin/check

Это предполагается:

Все разработчики находятся в группе dev (если нет, используйте имена пользователей или группы соответственно). Файлы находятся в /some/dir. Измените $SOURCE_DIR соответственно. Пользователем по умолчанию является nobody, а непроверенные файлы принадлежат пользователю по умолчанию. Никто не имеет прав на запись в исходный каталог, кроме root.

Затем разработчики могут выполнить:

sudo check some/file

, чтобы проверить /some/dir/some/file, и запустите его снова, чтобы проверить его.

Zanna · Answer 4 · 22 May 2018 в 18:30

Вы можете сделать это, хотя я думаю, что, возможно, более практичное решение, разработанное для такого сотрудничества.

В любом случае, вот что делать:

Создайте группу, добавьте пользователей в группу и предоставить группе право на запись в родительский каталог. Затем они смогут chown и chmod сохранить файл без использования sudo

Демонстрация:

sudo addgroup devs
sudo adduser zanna devs
sudo adduser pixie devs
mkdir development
chmod g+w development 
sudo chown root:devs development 
touch development/testfile
cd development
sudo chown root:devs testfile

Это настройка. Давайте проверим это:

zanna@xubi:~/development$ chown $USER testfile
$ stat -C "%U %G" testfile
zanna devs
$ chmod 600 testfile
$ stat -c %a testfile
600
$ su pixie
[enter password...]
pixie@xubi:/home/zanna/development$ chown $USER testfile
$ stat -c %U testfile
pixie

и т. Д. ... но это будет работать только при условии, что люди проверяют разрешения или пытаются записать в файл до того, как они начнут работать chown и chmod, который, вероятно, не интуитивно понятен ... И если у них есть разрешение на запись в родительский каталог, они всегда смогут принудительно записать файл, хотя они должны получить предупреждение, в зависимости от используемого им редактора.

Мне интересно, , что пользователь пытается достичь. Если это машина для разработки, почему имеет значение, если у разработчиков есть корень? И почему бы не использовать какую-то систему управления версиями? Или блокировка файлов? Для меня это звучит как проблема X-Y ... — vidarlo, 13 September 2017 в 21:17
проблема связана с проблемой блокировки файлов. Я работаю с GIT с bitbucket и bitbucket не поддерживает файлы блокировки GIT LFS: / — ILY, 13 September 2017 в 21:19
Это решает часть проблемы (chown), но если кто-то может проверить в любое время, значит, мы ничего не сделали, так как если я проверю, никто не должен проверять до тех пор, пока я не проведу проверку — ILY, 14 September 2017 в 10:39

Zanna · Answer 5 · 22 May 2018 в 18:30

Если пользователь имеет возможность запускать следующую команду sudo:

sudo bash

Он сможет выполнить любую команду с правами root, включая chown в любом файле. [!d1 ]

Вы можете настроить /etc/sudoers, чтобы позволить конкретному пользователю выполнять определенные команды

, например вы можете установить следующую строку в /etc/sudoers:

user2 ALL=(ALL) NOPASSWD: /bin/chown
user2 ALL=(ALL) NOPASSWD: /bin/chmod

Примечание: если у кого-то есть возможность запускать chown и chmod в качестве root, они могут легко получить полный доступ root (например, путем редактирования /etc/passwd)

3

ответ дан Zanna 22 May 2018 в 18:30

1

есть редактирование на моем посту, на самом деле я не хочу, чтобы он выполнял все команды, я просто хочу, чтобы у него была привилегия на chown и chmod – ILY 13 September 2017 в 17:38
2

@Ilyasse - наличие этих двух команд дает пользователю возможность получить полный доступ root ... – Yaron 13 September 2017 в 17:46
3

да, я собирался прокомментировать, что это по своей сути небезопасно, но последнее редактирование несколько фиксировало это – Zanna 13 September 2017 в 17:48
4

@Ilyasse - мой ответ - пример того, как ограничить доступ sudo к определенным командам. Если вы действительно хотите ограничить своего друга, не предоставляя полный доступ root, вы можете описать проблему real, с которой вы сталкиваетесь, и мы постараемся найти хорошее решение для ваших конкретных потребностей – Yaron 13 September 2017 в 17:54
5

я отредактировал сообщение, чтобы описать реальную проблему, с которой я сталкиваюсь – ILY 13 September 2017 в 20:13

jpezz · Answer 6 · 22 May 2018 в 18:30

Я согласен с тем, что sccs (Source Code Control System), включая исходную с начала 70-х, может быть хорошим решением для проверки в общих файлах, поскольку она поддерживает контроль версий, а также документацию об изменениях. [!d0 ]

Как дополнение к предложению Zanna, короткий скрипт, который проверяет, является ли пользователь владельцем, затем, если нет, проверяет, имеет ли группа разрешение на запись. Это означало бы, что он был проверен. Если он доступен, он будет chown, затем измените разрешения на 600 (файл занят). Чтобы освободить его, он изменит права доступа на 660. Таким образом, имя владельца будет указывать, кто заблокировал или кто последний заблокировал его, а групповое разрешение укажет, было ли оно доступно или все еще используется.

jpezz · Answer 7 · 18 July 2018 в 06:56

Я согласен с тем, что sccs (Source Code Control System), включая исходную с начала 70-х, может быть хорошим решением для проверки в общих файлах, поскольку она поддерживает контроль версий, а также документацию об изменениях.

Как дополнение к предложению Zanna, короткий скрипт, который проверяет, является ли пользователь владельцем, затем, если нет, проверяет, имеет ли группа разрешение на запись. Это означало бы, что он был проверен. Если он доступен, он будет chown, затем измените разрешения на 600 (файл занят). Чтобы освободить его, он изменит права доступа на 660. Таким образом, имя владельца будет указывать, кто заблокировал или кто последний заблокировал его, а групповое разрешение укажет, было ли оно доступно или все еще используется.

Zanna · Answer 8 · 18 July 2018 в 06:56

Если пользователь имеет возможность запускать следующую команду sudo:

sudo bash

Он сможет выполнить любую команду с правами root, включая chown в любом файле.

Вы можете настроить /etc/sudoers, чтобы позволить конкретному пользователю выполнять определенные команды

, например вы можете установить следующую строку в /etc/sudoers:

user2 ALL=(ALL) NOPASSWD: /bin/chown
user2 ALL=(ALL) NOPASSWD: /bin/chmod

Примечание: если у кого-то есть возможность запускать chown и chmod в качестве root, они могут легко получить полный доступ root (например, путем редактирования /etc/passwd)

jpezz · Answer 9 · 24 July 2018 в 18:42

Я согласен с тем, что sccs (Source Code Control System), включая исходную с начала 70-х, может быть хорошим решением для проверки в общих файлах, поскольку она поддерживает контроль версий, а также документацию об изменениях.

Как дополнение к предложению Zanna, короткий скрипт, который проверяет, является ли пользователь владельцем, затем, если нет, проверяет, имеет ли группа разрешение на запись. Это означало бы, что он был проверен. Если он доступен, он будет chown, затем измените разрешения на 600 (файл занят). Чтобы освободить его, он изменит права доступа на 660. Таким образом, имя владельца будет указывать, кто заблокировал или кто последний заблокировал его, а групповое разрешение укажет, было ли оно доступно или все еще используется.

Zanna · Answer 10 · 24 July 2018 в 18:42

Если пользователь имеет возможность запускать следующую команду sudo:

sudo bash

Он сможет выполнить любую команду с правами root, включая chown в любом файле.

Вы можете настроить /etc/sudoers, чтобы позволить конкретному пользователю выполнять определенные команды

, например вы можете установить следующую строку в /etc/sudoers:

user2 ALL=(ALL) NOPASSWD: /bin/chown
user2 ALL=(ALL) NOPASSWD: /bin/chmod

Примечание: если у кого-то есть возможность запускать chown и chmod в качестве root, они могут легко получить полный доступ root (например, путем редактирования /etc/passwd)

3

ответ дан Zanna 24 July 2018 в 18:42

1

есть редактирование на моем посту, на самом деле я не хочу, чтобы он выполнял все команды, я просто хочу, чтобы у него была привилегия на chown и chmod – ILY 13 September 2017 в 17:38
2

@Ilyasse - наличие этих двух команд дает пользователю возможность получить полный доступ root ... – Yaron 13 September 2017 в 17:46
3

да, я собирался прокомментировать, что это по своей сути небезопасно, но последнее редактирование несколько фиксировало это – Zanna 13 September 2017 в 17:48
4

@Ilyasse - мой ответ - пример того, как ограничить доступ sudo к определенным командам. Если вы действительно хотите ограничить своего друга, не предоставляя полный доступ root, вы можете описать проблему real, с которой вы сталкиваетесь, и мы постараемся найти хорошее решение для ваших конкретных потребностей – Yaron 13 September 2017 в 17:54
5

я отредактировал сообщение, чтобы описать реальную проблему, с которой я сталкиваюсь – ILY 13 September 2017 в 20:13
6

Мне интересно, , что пользователь пытается достичь. Если это машина для разработки, почему имеет значение, если у разработчиков есть корень? И почему бы не использовать какую-то систему управления версиями? Или блокировка файлов? Для меня это звучит как проблема X-Y ... – vidarlo 13 September 2017 в 21:17
7

проблема связана с проблемой блокировки файлов. Я работаю с GIT с bitbucket и bitbucket не поддерживает файлы блокировки GIT LFS: / – ILY 13 September 2017 в 21:19
8

Это решает часть проблемы (chown), но если кто-то может проверить в любое время, значит, мы ничего не сделали, так как если я проверю, никто не должен проверять до тех пор, пока я не проведу проверку – ILY 14 September 2017 в 10:39

Разрешить пользователям изменять принадлежность файла к определенному файлу без sudo

10 ответов

Другие вопросы по тегам:

Похожие вопросы: