Странное поведение linux: почему файлы под одним из пользователей создаются, но при записи в них содержимого удаляются?

Question

[Станислав]

Ситуация такова. Есть Debian 8, недавно он был Debian 7. В нем есть один пользователь (не с правами root'а), при работе с которым возникают странные вещи. По ssh подключиться через него невозможно, хотя таковая возможность ранее была. Команда `su -` также не помогает, консоль выглядит вот так:

15:05:23:root@server>~#su ouruser
Fri Mar 31 15:05:40 MSK 2017
15:05:40:root@server>~#

Лог /var/log/auth.log выглядит в этот момент так:

Mar 31 17:29:37 server su[2172]: Successful su for ouruser by root
Mar 31 17:29:37 server su[2172]: + /dev/pts/1 root:ouruser
Mar 31 17:29:37 server su[2172]: pam_unix(su:session): session opened for user ouruser by sshuser(uid=0)
Mar 31 17:29:37 server su[2172]: pam_unix(su:session): session closed for user ouruser

Где sshuser - это пользователь, под которым мы сначала попали на сервер по ssh, а потом уже при помощи `su -` попали под root, откуда и проводим эксперимент. Предупреждая вопросы - нет, из под sshuser тоже не получается попасть в нужного нам пользователя через `su -`. Остальные системные логи по grep ouruser ничего в этот момент не показывают.

Проверка через clamav и rkhunter тоже ничего не показала.

При подключении через ftp коннект происходит, однако тоже есть странности - при попытке создания некоего файла он создается, однако при последующей попытке записать в этот файл что-либо он просто исчезает.

Подскажите, в чем может быть проблема или с чего начать диагностику? Пересоздание пользователя в целом вариант, но крайний, и рассматриваться будет последним.

Answer 1

[Михаил Конюхов]

1. Это очень похоже на то, что вместо шелла у пользователя стоит /bin/date. Просто смените ему shell:

# chsh ouruser
Changing the login shell for ouruser
Enter the new value, or press ENTER for the default
	Login Shell [/bin/date]: /bin/bash

2. Так же может быть написан exit внутри profile или bashrc. тогда просто нужно найти эти строки и хотябы закоментить:

# egrep -i  -n '(exit|date)' /home/ouruser/.* 2>/dev/null
/home/ouruser/.bash_logout:1:# ~/.bash_logout: executed by bash(1) when login shell exits.
/home/ouruser/.bashrc:23:# update the values of LINES and COLUMNS.
/home/ouruser/.bashrc:114:date
/home/ouruser/.bashrc:115:exit
# mcedit -d /home/ouruser/.bashrc:114

3. Так же может быть какой то хак в /etc/profile или /etc/profile.d. Добавьте в /etc/profile в начало set -x

# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

set -x

if [ "`id -u`" -eq 0 ]; then

и сможете увидеть на какой команде происходит выход, а потом найти ее в файлах profile.

Comments

[Станислав]

Первый вариант подошел!

[Станислав]

Прошу прощения, но решение пока что неполное. Действительно, под пользователем стало возможно зайти в консоль, но файлы при их создании все также удаляются. Не подскажете, что можно попробовать сделать далее?

[Станислав]

На этот раз я пытаюсь создать под данным пользователем файл через vim, в его домашней директории, и вижу такой ответ:

E297: Write error in swap file
E303: Unable to open swap file for "11", recovery impossible
"11" [New File]
Press ENTER or type command to continue

[Станислав]

При этом файл создается и записывается как пустой, но если его попробовать потом заполнить чем-либо и сохранить, мы получим такое сообщение от vi:

"11" E514: write error (file system full?)

[Михаил Конюхов]

Скорее всего у вас занята всё место. Вывод df -h может с этим помочь:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/dm-0       917G  480G  391G  56% /
udev             10M     0   10M   0% /dev
tmpfs           6,3G   26M  6,3G   1% /run
tmpfs            16G 1012K   16G   1% /dev/shm
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs            16G     0   16G   0% /sys/fs/cgroup
......

Первое что можно удалить это излишек старых логов или мусор в /tmp, /var/tmp (если это допустимо удалять). После таких ситуаций следует - все такие не обойтись удалением только мусора и темпов, а вычистить то, что съело место, освободить хотябы несколько GB.
Если на сервере работает mysql/mariadb/percona - то произвести mysqlcheck и если потребуется repair таблиц. postgresql следует перезапустить, он сам почистит поломанные транзации.

Так же забить место и не освобождать могут файлы которые уже удалены, но открыты процессами:

# lsof | egrep -i deleted
php5-fpm  1286             root    4u      REG              254,0         0    5242884 /tmp/.ZendSem.uVMWc1 (deleted)
php5-fpm  1307             lynx    4u      REG              254,0         0    5242884 /tmp/.ZendSem.uVMWc1 (deleted)
php5-fpm  1308             lynx    4u      REG              254,0         0    5242884 /tmp/.ZendSem.uVMWc1 (deleted)
mysqld_sa 1324             root    1w      REG              254,0      1974   56624606 /var/log/mysql/error.log.1 (deleted)
mysqld_sa 1324             root    2w      REG              254,0      1974   56624606 /var/log/mysql/error.log.1 (deleted)

Такие процессы нужно просто перезапустить.

Но прежде чем что-то перезапускать/чекать освободите минимум места за счет мусора, это позволит не уронить сервер до конца.

[Станислав]

Михаил Конюхов: да, я уже проверял место, вот такая картина:

11:24:18:root@server>~#df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   43G  4.6G  91% /
udev             10M     0   10M   0% /dev
tmpfs           893M   73M  821M   9% /run
tmpfs           2.2G     0  2.2G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.2G     0  2.2G   0% /sys/fs/cgroup
tmpfs           217M     0  217M   0% /run/user/504

Папка пользователя находится в одной из папок в /var/www/. Возможно ли, чтобы был отдельный лимит для /var/? Возможно, стоить проверить квоты? Если да, то как? Я пробовал через quota, результат такой:

11:24:54:root@server>~#quota ouruser
Disk quotas for user ouruser (uid 503): none

[dummyman]

Станислав: так вся проблема только в этом. зачем домашнюю папку создавать в разделе /var ? Вот там при каждой перезагрузке будут пропадать не только файлы но и сама папка. И постоянно будет проблема с логином

[Станислав]

dummyman: хм, а почему там будут пропадать файлы, чем это обусловлено? По поводу того, почему сделано так, а не иначе - это вопрос к создателям ISPManager, от которого в итоге осталась именно такая архитектура сервера. При этом с остальными пользователями все в порядке, и они тоже были созданы именно в этой панели.

[dummyman]

никогда не использовал ISPManager, его необходимо удалять при покупке vds во избежание неловких моментов. /var - раздел специфичный, расчитан на постоянные изменения в нутри себя. Люди хранят там базы данных (/var/db), логи (/var/log), кэш (/var/cache), идентификаторы процессов и сокетов (/var/run), От того, если ssd, большие интервалы перед записью, чтобы не упарывать диск.

[Михаил Конюхов]

Станислав: дело в лимитах пользователя скорее всего. Если ISPManager там по прежнему стоит - подкрутите в панели. Если нет - то придется ковырять конфиги.

[Станислав]

dummyman: ну то есть все-таки нет некоего скрипта, который может таким образом чистить папку одного конкретного пользователя? Про ISPM в целом верное замечание, но тут уж что есть, то есть. Тогда вопрос остается в силе, почему таким интересным образом может вести себя система с одним конкретным пользователем. При этом напомню, что все остальные пользователи там живут отлично, как и этот, за единственным исключением - что при создании и заполнении файла через ftp, что при попытке сделать то же самое через ssh, файл удаляется в момент, когда в него что-то запишут.

[Михаил Конюхов]

Посмотрите в контаб в root: crontab -l , и в /etc/cron.d/* ISPManager держит там свои скрипты. Что у них там поменялось с очередной версией сложно угадать, но поведение похоже на то что их всё же удаляют.
Скорее всего пользователь упервся в дисковые квоты и ISP делает какую то магию.

[Станислав]

Михаил Конюхов: все найденные скрипты, завязанные на ISPM, удалил, остался только один в /etc/cron.d/, называется php5, выполняет /usr/lib/php5/sessionclean, который в свою очередь содержит код, который вряд ли может мешать. По поводу квот - да, была такая мысль, но как их проверить? Я пробовал через quota, вывод вот такой: "Disk quotas for user ouruser (uid 503): none". Возможно, можно как-либо еще проверить?

[Михаил Конюхов]

Станислав: Вот есть такая документация:

• https://wiki.archlinux.org/index.php/Disk_quota
  
• https://www.centos.org/docs/5/html/Deployment_Guid...
  

И бородатая статейка: https://www.opennet.ru/base/sys/linux_disk_quota2....

Вероятно она сможет помоч. Для начала посмотрите вывод mount и наличие опций usrquota

[Станислав]

В общем, я почистил часть файлов пользователя и файлы стали записываться. Однако, никаких признаков квот и переполнения диска мне так и не удалось найти. Если все-таки пойму, в чем дело, отпишусь тут отдельным ответом.

Answer 2

[Saboteur]

Выполните и покажите
cat /etc/passwd | grep ouruser
посмотрите как он настроен - где у него домашний каталог, какой у него шелл, какой у него UID.

Выполните df -h
Выполните df -h /var/www

Comments

[Станислав]

09:03:26:root@server>~#cat /etc/passwd | grep ouruser
ouruser:x:503:503:ouruser:/var/www/ouruser/data:/bin/bash

10:11:10:root@studio-sold>~#df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   43G  4.6G  91% /
udev             10M     0   10M   0% /dev
tmpfs           893M  8.5M  884M   1% /run
tmpfs           2.2G     0  2.2G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.2G     0  2.2G   0% /sys/fs/cgroup
tmpfs           217M     0  217M   0% /run/user/504

10:12:11:root@studio-sold>~#df -h /var/www
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   43G  4.6G  91% /

Вроде бы все хорошо?

[Saboteur]

А почему домашний каталог пользователя в /var/www, а не в /home?

Лучше добавить вашего пользователя в нужную группу, чтобы у него были права на запись в /var/www
/var/www/ouruser/data

Ошибка со swap, говорит что вы пытаетесь писать в виртуальную tmpfs систему.
Посмотрите права доступа к папкам:
ls -1lsFa /var/www/ouruser
ls -1lsFa /var/www

Посмотрите, другие пользователи в /etc/passwd тоже с домашним каталогом в /var/www? И права на их каталоги такие же?

[Станислав]

А почему домашний каталог пользователя в /var/www, а не в /home?

Это наследие от ISPManager. Понятно, что не слишком удобно, но уж как есть.

10:22:14:root@server>~#ls -1lsFa /var/www/ouruser
total 12
4 drwxrwxrwx  3 ouruser mgrsecure      4096 Apr 22  2015 ./
4 drwxr-xr-x 18 root           root           4096 Feb  7 15:43 ../
4 drwxrwxrwx  7 ouruser ouruser 4096 Apr  1 09:58 data/

10:22:22:root@server>~#ls -1lsFa /var/www
total 76
4 drwxr-xr-x 18 root             root      4096 Feb  7 15:43 ./
4 drwxr-xr-x 12 root             root      4096 Apr 21  2014 ../
4 drwxrwxrwx  3 ouruser   mgrsecure 4096 Apr 22  2015 ouruser/
4 dr-x-----x  3 ouruser1     mgrsecure 4096 Jun 30  2015 ouruser1/
4 dr-x-----x  3 ouruser2    mgrsecure 4096 Aug 11  2015 ouruser2/
...тут аналогичные пользователи...
4 drwxr-xr-x  2 root             root      4096 Sep 15  2016 html/
4 drwxr-x--- 14 root             root      4096 Apr 14  2016 httpd-cert/
4 drwxr-x--x  2 root             root      4096 Jan 23 23:33 httpd-logs/
4 -rw-r--r--  1 root             root       177 Apr 21  2014 index.html
4 drwxr-x--x  2 root             root      4096 Apr 21  2014 php-bin/

mgrsecure - это группа, которую использует ISMP для того, чтобы обеспечить права на доступ к папкам пользователей только для самих пользователей, вот тут об этом есть.

Посмотрите, другие пользователи в /etc/passwd тоже с домашним каталогом в /var/www? И права на их каталоги такие же?

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

[Saboteur]

Судя по камментам в другом ответе, проблема с логином была устранена, и даже немного удивительно, что вы изначально не заметили, что у других юзеров другой шелл.
С пропаданием файла - не знаю что может быть. Попробуйте выполнить это сейчас.
Еще раз проверьте как выглядят другие пользователи в /etc/passwd

[dummyman]

Станислав: Еще странен тот факт, что id пользователя и группы меньше 1000. Это точно не вручную созданный пользователь

[Saboteur]

dummyman: Ну это настраиваемая опция, и для нужд системы 500 ID более чем достаточно.

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

[Станислав]

В общем, я почистил часть файлов пользователя и файлы стали записываться. Однако, никаких признаков квот и переполнения диска мне так и не удалось найти. Если все-таки пойму, в чем дело, отпишусь тут отдельным ответом.