разрешение sed, отклоненное при использовании pam_exec с su

Я использую pam_mount.so для автоматического монтирования доли CIFS для пользователей на клиенте Ubuntu 14.04.

pam_mount использует локальный conf в каждом пользовательском корневом каталоге. Я запускаю скрипт удара с pam_exec, который обновляет конфигурационный файл с путем к доле CIFS.

Конец моего/etc/pam.d/common-session файл похож на это:

session required    pam_unix.so 
session optional    pam_exec.so log=/var/log/pamexec /usr/local/bin/mdrive_add
session optional    pam_mount.so 
session optional    pam_ldap.so 
session optional    pam_systemd.so

При входе в систему с SSH или через GUI, это работает, скрипт запущен перед монтированием, таким образом, доля доступна.

Однако при использовании su, сбои сценария и локальный пользователь conf не обновляется, таким образом, монтирование перестало работать также.

Ошибка, которую я получаю при использовании su от [accountA] до [accountB]:

/bin/sed: couldn't open temporary file /home/[accountB]/sednpoogQ: Permission denied

Строка в сценарии, который сбои - этот:

/bin/sed -i "s|\@S|${XSERVER}|g" /home/${PAM_USER}/.pam_mount.conf.xml

Я попытался запустить скрипт от ~/.profile и других мест, это работает безупречно, но не выполняется прежде pam_mount.

Таким образом, мой вопрос, как я могу заставить pam_exec заменять строку в текстовом файле, находящемся в корневом каталоге пользователя при использовании su?

Обновление

На комментарии я попробовал 'sudo-u [accountb]-i' (после включения @common-session в/etc/pam.d/sudo), и это не возвращает ту же ошибку, это работает. Однако это не приемлемое решение, поскольку я требую, чтобы su работал (и это вызывает подсказку пароля от pam_mount).

Update2

Я вошел в систему с ssh, вывели ENV в файл, и затем я вошел в систему с ssh из другой учетной записи, использовал su и вывел ENV в файл.

Сравнение двух (имена учетной записи, замененные accounta и accountb как в вопросе:

$ comm -3 <(sort ssh_list.txt ) <(sort su_list.txt)
    PASSWD_FD=0
    _PMT_DEBUG_LEVEL=0
    PWD=/home/[accounta]
PWD=/home/[accountb]
SHLVL=1
    SHLVL=2
    SSH_CLIENT=10.112.9.87 58090 22
SSH_CLIENT=10.112.9.87 58695 22
    SSH_CONNECTION=10.112.9.87 58090 10.80.0.68 22
SSH_CONNECTION=10.112.9.87 58695 10.80.0.68 22
SSH_TTY=/dev/pts/13
    SSH_TTY=/dev/pts/14
    XDG_RUNTIME_DIR=/run/user/1000
XDG_RUNTIME_DIR=/run/user/10006
    XDG_SESSION_ID=6
XDG_SESSION_ID=7

Update3

Добавленный полный скрипт, запущенный pam_exec (уязвимая информация, замененная заполнителями):

#!/bin/bash
USERN=$PAM_USER
if grep -q @S /home/${USERN}/.pam_mount.conf.xml || grep -q @P /home/${USERN}/.pam_mount.conf.xml; then
    BASEDIR=`ldapsearch -LLL -H ldaps://dc.example.org:3269 -D "account@example.org" -b "DC=c,DC=sdu,DC=dk" -w [secretpw] "sAMAccountName=${USERN}" dn`;
    PREFIX="dn:: "
    BASEDIR=${BASEDIR#$PREFIX}
    PREFIX="dn: "
    BASEDIR=${BASEDIR#$PREFIX}
    BASEDIR=`echo $BASEDIR | tr -d ' '`
    if [[ $BASEDIR != *","* ]]
        then
               BASEDIR=`echo $BASEDIR | base64 --decode`
        fi
    BASEDIR=`echo $BASEDIR | tr -d ' \n' | awk -F "DC=" '{ st = index($0,"DC=");print substr($0,st+0)}'`;
    DOMAIN=`echo $BASEDIR | sed 's/,DC=/./g' | sed 's/DC=//'`;
    OUTPUT=`ping -c 1 -t 10 $DOMAIN | grep icmp`
    HOMEDIR='\\fallbackserver\share'
    if [[ -n "$OUTPUT" ]]
        then
            DC=`echo $OUTPUT| cut -d' ' -f 4`
            HOMEDIR=`ldapsearch -LLL -H ldaps://$DC:636 -D "account@example.org" -b "${BASEDIR}" -w [secretpw] "sAMAccountName=${USERN}" homeDirectory | grep homeDirectory | awk '{print $2}'`;
        fi
    CHOMEDIR=$(echo ${HOMEDIR} | sed 's/\\/\//g')

    XSERVER=`echo $CHOMEDIR | cut -f3 -d/`
    XPATH=`echo $CHOMEDIR | cut -f4- -d/`



    /bin/sed -i "s|\@S|${XSERVER}|g" /home/${USERN}/.pam_mount.conf.xml
    /bin/sed -i "s|\@P|${XPATH}|g" /home/${USERN}/.pam_mount.conf.xml
fi

Update4

Помещая whoami в сценарий, шоу чем тогда, когда с помощью su от accounta до accountb, скрипт запущен accounta.

Update5

Используя 'seteuid' опцию с pam_exec решил проблему. session optional pam_exec.so seteuid log=/var/log/pamexec /usr/local/bin/mdrive_add

whoami теперь показывает 'корень' при переключении от до B и нет никаких проблем разрешения.

Я не понимаю условия 'идентификатор реального пользователя' и 'эффективный идентификатор пользователя' в руководстве для pam_exec, но это - вопрос в течение другого дня.

На значение по умолчанию pam_exec.so выполнит внешнюю команду с идентификатором реального пользователя обработки вызовов. Определение этой опции означает, что команда выполняется с эффективным идентификатором пользователя.

2
задан 8 October 2015 в 16:08

1 ответ

Проблема состояла в том, что вход в систему до su pam_exec выполнил сценарий как «старого» пользователя, у которого не было разрешения написать в корневой каталог «нового» пользователя.

Урегулирование seteuid выбор в session optional pam_exec.so log=/var/log/pamexec /usr/local/bin/mdrive_add сделал pam_exec, выполняют сценарий как корень, который решил проблему:

session optional pam_exec.so seteuid log=/var/log/pamexec /usr/local/bin/mdrive_add

Однако «реальное» решение, вероятно, настраивает /etc/pam.d/su соответственно, который является чем-то, с чем я все еще играю; я обновлю этот ответ, как только я понимаю правильный способ настроить /etc/pam.d/su.

0
ответ дан 9 October 2015 в 02:08
  • 1
    Были Вы в корректном каталоге, когда Вы сделали команду: cd ~/mt7610u Проверка, если файл там: ls Теперь попытка загрузить его: sudo insmod mt7610u.ko – chili555 30 December 2016 в 03:47

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

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