Права файлов в /etc (или выложите, пожалуйста, ls -Rl с рабочей системы -))

Knoppix

Модераторы: Warderer, Модераторы разделов

Аватара пользователя
sgfault
Сообщения: 586
Статус: -

Права файлов в /etc

Сообщение sgfault »

После очередного неудачного эксперимента (git checkout в /etc) сбросились права в /etc (ежу понятно, что ни о каком бекапе у меня и мысли не было). Не мог бы кто-нибудь выложить

Код: Выделить всё

$ ls -Rl /etc

с неиспорченной системы. Или может есть какие-то другие способы восстановить права файлов? Может их где-то сохраняет dpkg, и можно применить их еще раз?


Что же касается эксперимента, если кому интересно, я даже не считаю себя виноватым - это все он, etckeeper. Там делается предположение, что

Код: Выделить всё

$ git checkout

устанавливает права 755 или 644. Поэтому, сохраняет он только метаданные файлов с другими правами:

Код: Выделить всё

# cat /etc/etckeeper/pre-commit.d/30store-metadata
<..>
generate_metadata() {
    # This function generates the script commands to fix any files
    # that aren't owner=root, group=root, or mode=0644 or 0755.
    # The script is produced on stdout.  Errors go to stderr.
<...>
    # Find all directories that aren't 0755
    find $NOVCS -type d \! -perm 0755 \
        -exec stat --format="maybe chmod %a '{}'" {} \; | sort

    if [ "$VCS" = darcs ]; then
        # Find all files that aren't 0644 (darcs doesn't maintain
        # the executable bit).
        find $NOVCS -type f \! -perm 0644 \
            -exec stat --format="maybe chmod %a '{}'" {} \; | sort
    else
        # Find all files that aren't 0644 or 0755 (we can assume the VCS will
        # maintain the executable bit).
        find $NOVCS -type f \! -perm 0644 \! -perm 0755 \
            -exec stat --format="maybe chmod %a '{}'" {} \; | sort
    fi
<..>

Однако, как нетрудно убедиться, это предположение верно только с umask 022:

Код: Выделить всё

# ls -l passwd
-rw-r--r-- 1 root root 2472 Nov 21 18:41 passwd
# git checkout passwd
# ls -l passwd
-rw-r----- 1 root root 2472 Nov 21 21:44 passwd
# umask
0027

И тут-то и вспоминаешь невольно о несуществующем бекапе -)

PS. ОС Debian 6.
Спасибо сказали:
Аватара пользователя
Brainsburn
Сообщения: 950
Статус: /
ОС: Gentoo

Re: Права файлов в /etc

Сообщение Brainsburn »

drwxr-xr-x для каталогов и -rw-r--r-- для файлов (+х для исполняемых).

UPD:
На всякий: http://paste.pocoo.org/show/511029/
Спасибо сказали:
Аватара пользователя
sgfault
Сообщения: 586
Статус: -

Re: Права файлов в /etc

Сообщение sgfault »

Brainsburn писал(а):
21.11.2011 21:57
drwxr-xr-x для каталогов и -rw-r--r-- для файлов (+х для исполняемых).

А теперь посмотрите у себя

Код: Выделить всё

ls -l /etc/shadow

И как он? rw-r--r-- ? Уверяю вас, он такой не один.

upd
Однако, ваш совет подсказал мне отличную идею: ведь все файлы, права для которых не сохранил etckeeper, и правда были либо 644, либо 755. Так что спасибо -)
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Права файлов в /etc

Сообщение drBatty »

sgfault писал(а):
21.11.2011 21:59
И как он? rw-r--r-- ? Уверяю вас, он такой не один.

на самом деле зависит от используемого ПО.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Аватара пользователя
sgfault
Сообщения: 586
Статус: -

Re: Права файлов в /etc

Сообщение sgfault »

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

Первый способ (совсем простой и неинтересный).

Код: Выделить всё

# umask 022
# git checkout
# etckeeper init

Кстати, etckeeper из squeeze неправильно работает с пробелами в именах файлов (такие файлы создает, например, NM, если название подключения написано с пробелом). Вот патч из последующих версий etckeeper-а, который исправляет проблему:

Код: Выделить всё

--- a/etckeeper/init.d/20restore-etckeeper
+++ b/etckeeper/init.d/20restore-etckeeper
@@ -7,7 +7,7 @@ maybe () {
        command="$1"
        shift 1

-       if eval [ -e "\$$#" ]; then
+       if eval [ -e "\"\$$#\"" ]; then
                "$command" "$@"
        fi
 }


Второй способ (запутанный и сложный, зато интересный).
Воспользоваться скриптом, который, используя метаданные, сохраненные etckeeper-ом, восстановит метаданные для остальных файлов (которые должны были быть 644 или 755). Вот скрипт

Код: Выделить всё

#!/bin/sh
# Restore incorrect /etc permissions after `git checkout` if umask was not
# 022, using '.etckeeper' metadata save file.
#
# `etckeeper init` assumes, that `git checkout` sets permissions to either 644
# (no 'x') or to 755 ('x'), and, hence, does not remember mode for files with
# such modes.  But this is true only, if umask was 022. Otherwise, some files,
# which were originally 644 or 755, can become something like 640 or 750
# (umask 027) after `git checkout`.  `etckeeper init` can not restore mode for
# these files, because it simply does not save mode for them.
#
# However, for most cases etckeeper's metadata info is still enough to restore
# all modes correctly. Files, which are not in the '.etckeeper' have had mode
# either 644 or 755 originally. So, i just need to determine which one was
# executable and which one was not. I can do this by looking at executable
# bits unaffected by umask. In other words, i should find which (user, group
# or other) 'x' bit is not set in umask and check it in the file. If it is
# set, then `git` sets it and file was originally 755. Otherwise file was
# originally 644.
#
# But, unfortunately, this is not all. Any not remembered in '.etckeeper' file
# can be either tracked by vcs and had mode 644 or 755 originally, or
# _untracked_ by vcs and have any mode originally and now (its mode remains
# the same).  These ignored/untracked files can have arbitrary modes, which
# may be accidently considered as "broken 644" or "broken 755" and
# overwritten. To avoid this i should obtain list of such files from vcs and
# exclude it as well.


#   - Use '-f' to avoid interpreting special characters in filenames.
set -eufC

OIFS="$IFS"
readonly ret_success=0
readonly ret_error=1
readonly save_stdout=7
readonly save_pipe=9
readonly newline='
'

######
# This script works with git only.
VCS='git'
readonly etckeeper_meta='/etc/.etckeeper'
readonly etc_repository='/etc'
#####

# I'll use newline as IFS.
novcs="-wholename${newline}./.git${newline}-prune"
perm=''
# Files with 644 mode (no 'x' bit).
files=''
files_len=0
# Files with 755 mode.
x_files=''
x_files_len=0
# Files from etckeeper's metadata file with neither 644 nor 755 mode.
other_files=''
other_files_len=0
# Untracked by vcs files.
untracked_files=''
untracked_files_len=0

check_tmp_file()
{
    # Generate temp file name and check, that file can be created, but do
    # _not_ create. File name will have the form
    #
    #    "<user_defined_file_name>-<md5_of_file_content>"
    #
    # If file exist, such name allow to check its content.  If md5 will not
    # match, then file probably created by someone else and this is error.
    # File name returned on stdout.
    # Args:
    # 1    - file name (full path).
    # 2    - md5 of file content (may be with filename, may be not - it'll be
    # deleted anyway).
    #
    # Must _always_ be invoked in subshell.
    if [ $# -lt 2 ]; then
    return $ret_success
    fi
    local OIFS="$IFS"
    local ret=''
    local file_name="$1"
    local file_md5="$(echo "$2" | cut -d' ' -f1)"
    set -eufC
    eval "exec $save_pipe>&1 1>&$save_stdout"
    IFS="$newline"
    if [ "x$file_name" = 'x' ]; then
    return $ret_succes
    fi
    if [ ! -d "$(dirname "$file_name")" ]; then
    echo "$0: check_tmp_file(): Directory(s) does not exist for file '$file_name'"
    return $ret_error
    fi
    file_name="${file_name}-${file_md5}"
    if [ -f "$file_name" ]; then
    if [ "$(md5sum "$file_name" | cut -d' ' -f1)" != "$file_md5" ]; then
        echo "$0: check_tmp_file(): File exist, but has unexpected content."
        file_name=''
        ret=$ret_error
    fi
    fi
    eval "exec 1>&$save_pipe $save_pipe>&-"
    echo -n "$file_name"
    IFS="$OIFS"
    return $ret
}

exclude_files()
{
    # Exclude file names specified in arguments from list in stdin and write
    # result to stdout.
    # Args:
    # 1.. - file names to exclude.
    #
    # Must _always_ be invoked in subshell.
    local OIFS="$IFS"
    #   - Ensure, that '-e' grep option have arg (use ^\(.\)).
    local add_e_opt_regex='s/^\(.\)/-e\1/p'
    local grep_regex_args=''
    local grep_cmd=''
    local max_args=4
    local excl_patterns_file='/tmp/restore_etc'
    set -eufC
    eval "exec $save_pipe>&1 1>&$save_stdout"
    IFS="$newline"
    excl_patterns_file="$(
    check_tmp_file "$excl_patterns_file" "$(echo "$*" | md5sum)" || true
    )"
    if [ "x$excl_patterns_file" = 'x' ]; then
    # FIXME: Exceed max number of arguments.
    #   - Can't join several patterns into one arg, because of `grep -F`.
    #   - Can't call grep several times, because i need apply all patterns
    #   to stdin (i.e. i need pipe).
    #   - Can't call grep from pipe in eval with fixed number of args,
    #   because this require escaping special characters in args.
    # It seems, that file is the only good solution. But if it fails..

    #   - Omit empty args (sed -ne's///p').
    grep_regex_args="$(echo "$*" | sed -ne"$add_e_opt_regex")"
    else
    grep_regex_args="-f${newline}$excl_patterns_file"
    if [ ! -f "$excl_patterns_file" ]; then
        echo "$*" > "$excl_patterns_file"
    fi
    fi
    eval "exec 1>&$save_pipe $save_pipe>&-"
    #   - Use '-F' to avoid interpreting special characters in filenames.
    #   - Use '-x' to ensure correct matching.
    grep -v -Fx ${grep_regex_args:--e ''}
    IFS="$OIFS"
    return $ret_success
}

set_mode()
{
    # Set specified mode for files specified in arguments.
    # Args:
    # 1        - octal file mode.
    # 2..   - files, which mode to set.
    if [ $# -lt 2 ]; then
    return $ret_success
    fi
    local OIFS="$IFS"
    local perm="$1"
    shift
    if echo "$perm" | grep -q -e'[^[:digit:]]'; then
    echo "$0: set_mode(): Incorrect mode '$perm'"
    return $ret_error
    fi
    echo "Files which should be '$perm':"
    echo "$*" \
    | xargs -d'\n' stat -c '%a %n' \
    | sed -ne"/^$perm /!s/[^ ]\+ //p" \
    | xargs -d'\n' bash -c 'echo "## $#:"; for ((i = 1; i <= $#; i++)); do echo "$i: ${!i}"; done' bash $perm
# FIXME: Replace above line with
#    | xargs -r -d'\n' chmod -c $perm
# for actual operation.
    IFS="$OIFS"
    return $ret_success
}

eval "exec $save_stdout>&1"
IFS='
'

# Set all 'x' bits in finds '-perm /ZZZ', which is not affected by umask. I
# need at least one unaffected by umask 'x' bit to continue.
perm="$(printf "%o" $(( ($(umask) & 0111) ^ 0111 )) )"
if [ "$perm" -eq '0' ]; then
    echo "$0: Can't restore mode with umask '$(umask)'"
    exit $ret_error
fi
perm="-perm${newline}/$perm"

cd "$etc_repository"
# Generate exclude file lists.
if [ -f "$etckeeper_meta" ]; then
    #    - Omit empty files (use '\(.\+\)').
    other_files="$(
    sed -ne"/^maybe chmod/s/^\([^ ]\+ \+\)\{3\}'\(.\+\)'/\2/p" "$etckeeper_meta"
    )"
    other_files_len="$(echo "$other_files" | wc -l)"
fi
if [ "$VCS" = 'git' ]; then
    untracked_files="$(git ls-files -o | sed -e's:^:\./:')"
else
    echo "$0: Can't generate untracked files list"
fi

# Generate 644 and 755 mode file lists.
files="$(
    find . $novcs -o -type f -not $perm -print \
    | exclude_files ${other_files:-} ${untracked_files:-}
)"
x_files="$(
    find . $novcs -o -type f      $perm -print \
    | exclude_files ${other_files:-} ${untracked_files:-}
)"
files_len="$(echo "$files" | wc -l)"
x_files_len="$(echo "$x_files" | wc -l)"

echo "644 files = $files_len"
echo "755 files = $x_files_len"
echo "other files = $other_files_len"

# Use '-d\n' for separating arguments by newline instead of blanks (default),
# and for interpreting all characters literally (disable escape characters).
set_mode 644 "$files"
set_mode 755 "$x_files"

eval "exec $save_stdout>&-"
IFS="$OIFS"


Третий способ (самый надежный, наверное -).
Запускаете где-то на неиспорченном /etc

Код: Выделить всё

# find -type f | xargs -d'\n' stat -c '%a %n' >./ref_mode.txt

а затем проверяете свой /etc как-то так

Код: Выделить всё

$ cat ./ref_mode.txt | xargs -d'\n' -L1 bash -c 'if [ ! -f "${1#* }" ]; then exit 0; fi; if [ "$(stat -c "%a %n" "${1#* }")" != "$1" ]; then echo "Mode not match for \"$1\""; fi'  bash


Вот, собственно, и все.

PS. Если что, продолжение обсуждения здесь bugs.debian.org/649701 -)
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Права файлов в /etc

Сообщение drBatty »

sgfault писал(а):
23.11.2011 17:05
Третий способ (самый надежный, наверное -).

поймите, что-бы восстановить права надо иметь файлы. Мой /etc/ вам не пойдёт например потому, что у меня нет NW, а у вас есть.
И так с любой программой.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Xandry
Сообщения: 980
ОС: openSUSE

Re: Права файлов в /etc

Сообщение Xandry »

Как радикальный способ - можно просто переустановить все установленные пакеты.
Спасибо сказали:
Аватара пользователя
sgfault
Сообщения: 586
Статус: -

Re: Права файлов в /etc

Сообщение sgfault »

drBatty писал(а):
23.11.2011 17:19
sgfault писал(а):
23.11.2011 17:05
Третий способ (самый надежный, наверное -).

поймите, что-бы восстановить права надо иметь файлы. Мой /etc/ вам не пойдёт например потому, что у меня нет NW, а у вас есть.
И так с любой программой.

NW? Может вы хотели сказать NM?
В любом случае, не вижу в этом никакой проблемы. Это лишь означает, что с вашего /etc (если предположить, что под слакой права соответствующих файлов такие же, как в дебиане 6), я не смогу восстановить права _части_ файлов. Ну так что ж, сделаю это с /etc кого-нибудь другого.

Xandry писал(а):
23.11.2011 17:31
Как радикальный способ - можно просто переустановить все установленные пакеты.

Я считаю, в случае с потерянными правами в этом нет никакой необходимости. Как я уже написал выше, использовав права из /etc других систем с дебиан 6, можно восстановить либо все, либо почти все файлы. Причем последнее только, если не удастся найти человека, у которого были бы установлены эти несколько пакетов. И в этом случае, возможно, будет иметь смысл переустановить лишь эти несколько оставшихся пакетов.
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Права файлов в /etc

Сообщение drBatty »

sgfault писал(а):
23.11.2011 18:18
В любом случае, не вижу в этом никакой проблемы. Это лишь означает, что с вашего /etc (если предположить, что под слакой права соответствующих файлов такие же, как в дебиане 6), я не смогу восстановить права _части_ файлов. Ну так что ж, сделаю это с /etc кого-нибудь другого.

хм... оригинально. Может проще тогда
Xandry писал(а):
23.11.2011 17:31
переустановить все установленные пакеты.

?
А то ведь вам надо способ ещё и найти и поставить эти права - что поставилось, а что надо бежать дальше, за новой /etc/

Кстати, ИМХО задача решаема ручкам:
1. ставим права root:root 0700 на каталоги
2. ставим права в каталоги, куда могут попасть простые юзеры 0755 (файлы 0644 root:root))
3. ставим права на каталоги, в которые могут ходить демоны, запущенные не от рута.
sgfault писал(а):
23.11.2011 18:18
Я считаю, в случае с потерянными правами в этом нет никакой необходимости.

есть ещё вариант:
1. сконвертируйте пакет в слакварный
2. слакварный пакет == обычный tar архив. Потому tar -tvvf package покажет права.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Аватара пользователя
sgfault
Сообщения: 586
Статус: -

Re: Права файлов в /etc

Сообщение sgfault »

drBatty писал(а):
23.11.2011 21:48
sgfault писал(а):
23.11.2011 18:18
В любом случае, не вижу в этом никакой проблемы. Это лишь означает, что с вашего /etc (если предположить, что под слакой права соответствующих файлов такие же, как в дебиане 6), я не смогу восстановить права _части_ файлов. Ну так что ж, сделаю это с /etc кого-нибудь другого.

хм... оригинально. Может проще тогда
Xandry писал(а):
23.11.2011 17:31
переустановить все установленные пакеты.

?
А то ведь вам надо способ ещё и найти и поставить эти права - что поставилось, а что надо бежать дальше, за новой /etc/

Не понимаю о каком способе речь, и не вижу тут совершенно никаких трудностей. Какой-то командой типа упомянутой выше

Код: Выделить всё

# find -type f | xargs -d'\n' stat -c '%a %n'

составляется список файлов с правами с других дебиан 6 систем. Затем пишется скрипт, который объединяет эти списки, сравнивает права файлов с совпавшими именами с правами файлов в моем, испорченном /etc и восстанавливает в случае различия. Кроме этого, возможно, надо будет учесть различия в файлах /var/lib/dpkg/statoverride. После этого либо все файлы оказываются проверенными, либо абсолютное большинство. Чтобы восстановить права для оставшихся можно либо найти еще логи с /etc, либо переустановить эти пакеты, либо сделать это вручную. В результате - ручной работы минимум. Вряд ли не найденных файлов будет больше 10%. Скрипт я вам писать не буду, тк у себя все восстановил, и эта задача мне больше неинтересна.

drBatty писал(а):
23.11.2011 21:48
Кстати, ИМХО задача решаема ручкам:
1. ставим права root:root 0700 на каталоги
2. ставим права в каталоги, куда могут попасть простые юзеры 0755 (файлы 0644 root:root))
3. ставим права на каталоги, в которые могут ходить демоны, запущенные не от рута.
sgfault писал(а):
23.11.2011 18:18
Я считаю, в случае с потерянными правами в этом нет никакой необходимости.

есть ещё вариант:
1. сконвертируйте пакет в слакварный
2. слакварный пакет == обычный tar архив. Потому tar -tvvf package покажет права.

Как я написал выше не вижу смысла делать это полностью вручную, если можно сделать _бо'льшую_ часть работы автоматически.

И, вообще, я не понимаю, что вы мне доказываете? Что я не смогу восстановить права, используя логи с правами файлов с других систем? Или что я не смогу восстановить автоматически?
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Права файлов в /etc

Сообщение drBatty »

sgfault писал(а):
23.11.2011 23:20
Не понимаю о каком способе речь

sgfault писал(а):
23.11.2011 18:18
сделаю это с /etc кого-нибудь другого.

везёт вам - вокруг полно линуксоидов, и у всех разные /etc/ :)
sgfault писал(а):
23.11.2011 23:20
Как я написал выше не вижу смысла делать это полностью вручную, если можно сделать _бо'льшую_ часть работы автоматически.

И, вообще, я не понимаю, что вы мне доказываете?

ручной способ подойдёт для осознания, и для собственного развития ПОЧЕМУ так.
второй способ (deb->txz->tar->list) полностью автоматизируется, и имеет 99% эффект (ошибка только если в репах что-то изменилось)
А ваш способ(ы) какой(ето) неправильный(е). ИМХО.
ЗЫЖ читайте подпись.
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
Аватара пользователя
sgfault
Сообщения: 586
Статус: -

Re: Права файлов в /etc

Сообщение sgfault »

drBatty писал(а):
24.11.2011 02:18
sgfault писал(а):
23.11.2011 23:20
Не понимаю о каком способе речь

sgfault писал(а):
23.11.2011 18:18
сделаю это с /etc кого-нибудь другого.

везёт вам - вокруг полно линуксоидов, и у всех разные /etc/ :)

Дебиан 6 такая редкая система, а, если и найдется у кого, то все они такие разные, что если и там, и там будет пара файлов с одинаковым _названием и правами_ (а не содержанием!) - то это уже бооольшая удача, ага?

drBatty писал(а):
24.11.2011 02:18
sgfault писал(а):
23.11.2011 23:20
Как я написал выше не вижу смысла делать это полностью вручную, если можно сделать _бо'льшую_ часть работы автоматически.

И, вообще, я не понимаю, что вы мне доказываете?

ручной способ подойдёт для осознания, и для собственного развития ПОЧЕМУ так.

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

drBatty писал(а):
24.11.2011 02:18
второй способ (deb->txz->tar->list) полностью автоматизируется, и имеет 99% эффект (ошибка только если в репах что-то изменилось)
А ваш способ(ы) какой(ето) неправильный(е). ИМХО.
ЗЫЖ читайте подпись.

Что касается моих способов, то первые два - это вообще решения _конкретной_ проблемы с etckeeper-ом, и в случае возникновения именно _этой_ проблемы (как и было у меня) они оба (или хотя бы первый) уж точно наааамного проще и 3-го, и ваших манипуляция с пакетами.

А заодно, укажите что ли список причин, почему мои способы так неправильны? И, наконец, то, что вы предлагаете, будет отличаться от описанной мной схемы _только_ способом получения исходных данных: я их предполагал брать из логов с других систем, а вы предлагаете брать из deb пакетов. В результате и там, и там получится список файлов с правами. И мой способ имеет преимущество в том, что он требует меньше знаний - не зная в точности всех деталей конвертации (а я их не знаю, тк никогда это не делал и не собираюсь), я бы не стал ее использовать, - а значит при их (знаний) отсутствии реализуется значительно быстрее.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

Re: Права файлов в /etc

Сообщение watashiwa_daredeska »

drBatty писал(а):
24.11.2011 02:18
второй способ (deb->txz->tar->list) полностью автоматизируется, и имеет 99% эффект
У меня ~85%. Если верить dpkg -S, то ~15% файлов в /etc не относятся ни к какому пакету. Нынче многие пакеты рулят своими конфигами из install-скриптов.
Спасибо сказали:
Аватара пользователя
drBatty
Сообщения: 8735
Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит...
ОС: Slackware-current

Re: Права файлов в /etc

Сообщение drBatty »

sgfault писал(а):
24.11.2011 11:40
Ах, так вот в чем дело. Вы предалагете мне "осознать" и понять "почему так". Я вас разочарую, мне нужен был только восстановленный /etc, и в рамках данной задачи мне было совершенно безразлично "почему оно так".

ну это уже другая проблема.
sgfault писал(а):
24.11.2011 11:40
А заодно, укажите что ли список причин, почему мои способы так неправильны? И, наконец, то, что вы предлагаете, будет отличаться от описанной мной схемы _только_ способом получения исходных данных: я их предполагал брать из логов с других систем

как я понял, не из логов, а просто из других систем. Это не надёжно.
sgfault писал(а):
24.11.2011 11:40
я бы не стал ее использовать, - а значит при их (знаний) отсутствии реализуется значительно быстрее.

ладно. что спорить-то?

Я вам только одно скажу - неправильная расстановка прав == РЕШЕТО.
Можете поставить на всё 3777, и у вас будет полный УМВР. И знаний никаких не нужно. Без вопросов. Тема закрыта.

watashiwa_darede... писал(а):
24.11.2011 12:31
У меня ~85%. Если верить dpkg -S, то ~15% файлов в /etc не относятся ни к какому пакету. Нынче многие пакеты рулят своими конфигами из install-скриптов.

вынужден согласится.
(за кадрам остаётся вопрос: зачем пакетам рулить правами, если это умеет старый добрый tar?)
http://emulek.blogspot.ru/ Windows Must Die
Учебник по sed зеркало в github

Скоро придёт
Осень
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

Re: Права файлов в /etc

Сообщение watashiwa_daredeska »

drBatty писал(а):
24.11.2011 15:05
за кадрам остаётся вопрос: зачем пакетам рулить правами, если это умеет старый добрый tar?
Я не уверен, что они рулят правами. Просто, если я правильно помню грабли, по которым ходил при пакетировании, в dpkg есть недостаток: если пакету не достаточно просто положить фиксированный конфиг, чтобы получить работоспособность, а надо модифицировать его на основании, например, ответов пользователя в debconf или на основании конфигурации чего-нибудь другого, то если объявить этот конфиг в пакете конфигом, то dpkg впоследствии затрахает пользователя вопросом: «Пакет хочет установить новый конфиг, но конфиг в системе был изменен вручную. Чо делать?». Некоторые пакеты, кстати, этим грешат.

А права при этом могут быть вполне обычные 0644.
Спасибо сказали:
Аватара пользователя
diesel
Бывший модератор
Сообщения: 5989
ОС: OS X, openSuSE, ROSA, Debian

Re: Права файлов в /etc

Сообщение diesel »

drBatty писал(а):
24.11.2011 15:05
Можете поставить на всё 3777, и у вас будет полный УМВР.

не будет :)
наиболее близкий к реальности вариант: 755 на директории, 644 на файлы и потом чинить все что отвалилось.
Спасибо сказали:
Аватара пользователя
sgfault
Сообщения: 586
Статус: -

Re: Права файлов в /etc

Сообщение sgfault »

drBatty писал(а):
24.11.2011 15:05
sgfault писал(а):
24.11.2011 11:40
А заодно, укажите что ли список причин, почему мои способы так неправильны? И, наконец, то, что вы предлагаете, будет отличаться от описанной мной схемы _только_ способом получения исходных данных: я их предполагал брать из логов с других систем

как я понял, не из логов, а просто из других систем. Это не надёжно.

Что значит "просто из других систем" ? Под логами я имел в виду вывод чего-то типа stat -c '%a %n', запущенного на всем /etc. Да и, к тому же, не просто "из других систем", а из дебиан 6 систем.

drBatty писал(а):
24.11.2011 15:05
sgfault писал(а):
24.11.2011 11:40
я бы не стал ее использовать, - а значит при их (знаний) отсутствии реализуется значительно быстрее.

ладно. что спорить-то?

Я вам только одно скажу - неправильная расстановка прав == РЕШЕТО.
Можете поставить на всё 3777, и у вас будет полный УМВР. И знаний никаких не нужно. Без вопросов. Тема закрыта.

Увы, я сам ничего ставить не собирался с самого начала. Оно будет ставиться само. И, если мне очень-очень повезет и попадется система с 3777 (зачем, кстати, ставить 1000? Без него ведь намного удобнее стирать файлы) на всем /etc, то-таки да, ваши ожидания оправдаются, и мой неправильный метод сделает решето. Но интуиция подсказывает мне, что вероятность этого настолько мала (а при минимальных мерах предосторожности так и вовсе никакой), что уж где-где, а тут точно все будет нормально. А тема, да, закончилась уже давно, еще на 5-ом сообщении, если что.
Спасибо сказали: