Отказано в разрешении sed при использовании pam_exec с su
Я использую pam_mount.so для автоматического монтирования общего ресурса CIFS для пользователей на клиенте Ubuntu 14.04.
pam_mount использует локальный conf в каждом домашнем каталоге пользователя. Я запускаю скрипт bash с 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 или через графический интерфейс это работает, скрипт запускается перед монтированием, поэтому общий ресурс доступен.
Однако при использовании 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 теперь показывает "root" при переключении с A на B, и нет никаких проблем с разрешениями.
Я не понимаю терминов "реальный идентификатор пользователя" и "эффективный идентификатор пользователя" в руководстве для pam_exec, но это вопрос другого дня.
По умолчанию pam_exec.so будет выполнять внешнюю команду с реальным идентификатором пользователя вызывающего процесса. Указание этого параметра означает, что команда запускается с эффективным идентификатором пользователя.
1 ответ
Проблема заключалась в том, что вход в систему через su
pam_exec
выполнил скрипт как "старый" пользователь, у которого не было разрешения на запись в домашний каталог "нового" пользователя.
Настройка seteuid
вариант в session optional pam_exec.so log=/var/log/pamexec /usr/local/bin/mdrive_add
сделал pam_exec
выполнить скрипт от имени root, что решило проблему:
session optional pam_exec.so seteuid log=/var/log/pamexec /usr/local/bin/mdrive_add
Однако "реальным" решением, вероятно, является настройка /etc/pam.d/su
адекватно, это то, что я все еще возился; Я обновлю этот ответ, как только пойму правильный способ настройки /etc/pam.d/su
,