Сейчас подумал, что было бы забавно иметь двухуровневую систему пользователей.

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

;)

определённые права на группу и владельца директорий, файлов, не?

Нужно как-то ограничивать доступ к файлам из под одного и того же пользователя.

Владелец файла может читать файл, записывать, удалять, но только после ввода пароля? И при этом лень заводить пользователей, но для каждого ученика не лень ввести пароль на файл, и заморочиться с настройкой?

Но необходимо как-то сохранять работы каждого ученика таким образом, чтобы другие ученики того же класса не могли прочитать, изменить или удалить данные конкретного ученика.

Если работы КАЖДОГО ученика, то КАДОМУ нужен свой пароль. Так что особого выигрыша по сравнению с обычной системой, где каждый ученик представлен отдельным пользователем нет.

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

Если работы КАЖДОГО ученика, то КАДОМУ нужен свой пароль.

Да, но тонкость в том, что далеко не всегда нужно сохранять данные в запароленные папки. Чаще всего достаточно общего пользователя на класс.

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

Ну и настроить окружение для всех пользователей будет тем сложнее чем их будет больше. Одно дело создать и настроить 10 пользователей на классы, а другое дело создать, настроить и помнить все пароли на 250+ человек.

Ну и настроить окружение для всех пользователей будет тем сложнее чем их будет больше. Одно дело создать и настроить 10 пользователей на классы, а другое дело создать, настроить и помнить все пароли на 250+ человек.

Всё это легко автоматизируется и да:

помнить все пароли

а это зачем? Если забыл - заводить новый.

Но необходимо как-то сохранять работы каждого ученика таким образом, чтобы другие ученики того же класса не могли прочитать, изменить или удалить данные конкретного ученика.

Просто запретить им на этой самой шаре удалять, читать и изменять файлы (т.е. можно только заливать)

Или на худой конец сделать это в виде веб-формы

Ну, пользователь должен ведь зайти под своим конкретным аккаунтом, невозможно заходить под группой. ;)

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

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

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

Но это всё равно неудобно и геморойно т.к. от имени выбранного пользователя будут запускаться только программы из под консоли.

Всё это легко автоматизируется

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

Логины и пароли мне помнить необходимо, т.к. ученики часто забывают и логины и пароли. (в рамках одного класса, логины и пароли трудно сохранить в секрете, т.к. ученики обмениваются друг с другом информацией, пароли можно подсмотреть и т.п. в этом смысле пароли на папки были бы удобней с точки зрения эксплуатации, т.к. их придётся вводить реже, а пароли смогут задавать сами ученики. Но конечно, пользователь с админскими правами должен иметь доступ ко всем папкам.)

Кроме того, мне необходимо иметь возможность легко ориентироваться в данных пользователей (что они скачали, что принесли на флешке и т.п.) если пользователей будет много, это усложнит прочёсывание всех папок.

Ну и ещё я должен иметь возможность настраивать внешний вид, содержание менюшек, доступ к тем или иным программам для каждого класса (хотя, что-то из этого можно делать через группы).

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

запретить им на этой самой шаре удалять, читать и изменять файлы (т.е. можно только заливать)

Вариант, но не всегда и не для всех видов деятельности подходит.

В логин скрипте чистить хомяк от всех посторонних файлов

запихнуть простейший скрипт

Да, похоже на вариант.

спрашивать пароль от шары и монтировать её

Вот то как это должно функционировать я не очень понял. Скрипт для монтирования - это легко. Но кто проверяет пароли и как это реализуется?

В логин скрипте чистить хомяк от всех посторонних файлов

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

Но кто проверяет пароли и как это реализуется?

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

А скрипт должен просто выводить окошко (чем-нибудь вроде xdialog) с полями юзер/логин и пытаться смонтировать.

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

Данные для пользователя. Так вот как теперь шпаргалки называются. Хм.

Да, интересно. Подскажите какие мануалы нужно копать, я попробую поразбираться.

По совсем плохому достаточно просто зашифровать файл но пароль а соответственно и ответственность будет на самом ученике. Т.е. «а я забыл» будет виноват он сам так же как и если он либо просто забудет запаролить. Либо как либо велосипедить на эту тему…

По хорошему каждому ученику свой пользователь (в «киоске» ага а хомяк все так же с общего сервера и чистим его после разлогинивания). А дальше на сервере в любой vcs доступ пользователю по индивидуальному ключу и только по ssh. Профит: в идеале получаем историю т.е. можно писать красивые отчеты что, когда и в каком объеме выполнено; кроме того vcs это все же vcs и в том же git-е ветви, и откатывание на ранние версии иногда ну просто незаменимая вещь; имея административные привилегии на сервере можно получить доступ к работам любых учеников.

По самбе вроде вот: https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/pam.html

xdialog (или какой-нибудь ssh-askpass) это уже в их мануалах.

вебинтерфейс на перле или том языке

Правильное решение - толстые общие тетради, прикованые цепью к парте. Компьютеры вам строго противопоказаны.

Правильное решение - толстые общие тетради, прикованые цепью к парте. Компьютеры вам строго противопоказаны.

Нет. Недостаточно вандалоустойчивы ;)

К тому же толку от них будет мало, поскольку ученики писать то еле-еле умеют.

Посмотри в сторону zentyal, может тебе пригодится эта штука для твоих опытов. У меня работает. Правда, пользователей у меня около 50.

Пришёл в голову такой вариант. На каталог ставим sticky-бит, чтобы только владелец мог удалять файл. В системе заводим двух пользователей user и secur. Ученики работают от user, нужные для сохранения файлы передаются во владение пользователю secur.

Для передачи файла пишем простейший скрипт, запускаемый через sudo, который где-то хранит таблицу:

файл <-> пароль <-> дата (чтобы как-то идентифицировать)

Скрипт берёт на вход имя файла и смотрит, если файл пренадлежит user, нужно запросить пароль, занести его в таблицу, переназначить файл пользователю secur. Если файл пренадлежит пользователю secur, нужно запросить пароль, проверить, в случае совпадения удалить из таблицы и переназначить файл пользователю user.

Скрипт засовываем в менюшку файлового менеджера. Пароли храним открытым текстом, файлы не шифруем, чтобы не было проблем, всё одно система простейшая, для детей.

Скрипт, вроде, не сложный, ИМХО, основная проблема будут всякие неправильные имена файлов — с пробелами, переносами строк и др. служебными символами. Поэтому может хранить иноды или имена в hexdump'е.

Какой-то очень тонкий вброс. Поднять LDAP тоже почему-то не предложили.

простейший скрипт, запускаемый через sudo

Т.е. user сможет запускать программы через sudo? Нет, это не катит. Они же всю систему так смогут порушить. ;)

Т.е. user сможет запускать программы через sudo? Нет, это не катит. Они же всю систему так смогут порушить. ;)

man sudoers

Они же всю систему так смогут порушить

Если sudoers будет править админ вроде тебя, то несомненно так и будет.

USB флешка с ключом + PAM

Можно замутить аутентификацию пользователей по ключу на USB-флешке через модули PAM. И помнить ничего не надо. А флешку на веревочку на шею повесить или клипсой к уху прицепить.

файл <-> пароль <-> дата (чтобы как-то идентифицировать)

можно в расширенных атрибутах хранить md5+salt пароля.

Скрипт берёт на вход имя файла и смотрит, если файл пренадлежит user, нужно запросить пароль, занести его в таблицу, переназначить файл пользователю secur. Если файл пренадлежит пользователю secur, нужно запросить пароль, проверить, в случае совпадения удалить из таблицы и переназначить файл пользователю user.

ещё неплохо сбросить право чтения файла для всех и для группы.

Пароли храним открытым текстом, файлы не шифруем, чтобы не было проблем, всё одно система простейшая, для детей.

ты недооцениваешь детей.

Скрипт, вроде, не сложный, ИМХО, основная проблема будут всякие неправильные имена файлов — с пробелами, переносами строк и др. служебными символами.

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

Т.е. user сможет запускать программы через sudo?

нет. sudo проверяет, кто, откуда, с чьего имени, как, и что запускает. Никто не заставляет делать как в бубунте: откуда угодно, с имени root, и что угодно.

Они же всю систему так смогут порушить

не смогут.

Кстати, совсем забыл ещё одну важную причину, по которой не получится сделать каждому ученику свой собственный аккаунт для работы:

Во многих классах ученикам приходится работать за одним компьютером по 2 или даже по 3.

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

Бывало приходилось сажать за 11 компов (и 11 стульев) классы по 25-29 человек. Стулья они искали по всей школе, но столов всё равно не было, поэтому писали на коленке или открывая шкаф и садясь внутрь него.

Сейчас проблему со столами и стульями я решил, но количество компьютеров всё равно ограничено.

Можно ли под Линуксом ограничить доступ к файлам только по паролю?

ну вот такой скрипт набросал на скорую руку:

#!/bin/bash

SSHARE_USER="sshare"
SSHARE_DIR="/home/sshare"
SSHARE_MODE="0600"

SALT="НЁХ"

XATTR_PREFIX="user.sshare_"

REPLY=""

FILENAME="$1"

if [ ! -f "$FILENAME" ]; then
	echo "Файл '$FILENAME' не существует."
	exit 67
fi

FILE_OWNER=$(stat --printf="%U" "$FILENAME")
FILE_MODE=$(stat --printf="%a" "$FILENAME")
if [ "$FILE_OWNER" != "$SSHARE_USER" ]; then
	while [ "$REPLY" == "" ]; do
		read -s -p"Введите пароль для шифрования '$FILENAME': "
		PASSWORD1="$REPLY"
		echo
		read -s -p"Повторите пароль: "
		PASSWORD2="$REPLY"
		echo
		if [ "$PASSWORD1" != "$PASSWORD2" ]; then
			echo "Пароли не совпадают, пожалуйста повторите."
			REPLY=""
			continue
		fi
		PASSWORD1="${PASSWORD1}${SALT}"
		HASH=$(echo "$PASSWORD1" | md5sum | sed 's/\s.*//')
		echo "User: $FILE_OWNER, Mode: $FILE_MODE, Hash: $HASH"
		chown --verbose "$SSHARE_USER" "$FILENAME" | exit
		chmod --verbose "$SSHARE_MODE" "$FILENAME" | exit
		setfattr -n "${XATTR_PREFIX}password" -v "$HASH" "$FILENAME" | exit
		setfattr -n "${XATTR_PREFIX}owner" -v "$FILE_OWNER" "$FILENAME" | exit
		setfattr -n "${XATTR_PREFIX}mode" -v "$FILE_MODE" "$FILENAME" | exit
		echo "Файл защищён."
		break
	done
else
	read -s -p"Файл '$FILENAME' защищён, введите пароль доступа: "
	echo
	PASSWORD1="${REPLY}${SALT}"
	HASH=$(echo "$PASSWORD1" | md5sum | sed 's/\s.*//')
	F_HASH=$(getfattr -n "${XATTR_PREFIX}password" "$FILENAME" | sed -rn 's/^'"${XATTR_PREFIX}password"'="([[:xdigit:]]{32})"\s*$/\1/p')
	FILE_OWNER=$(getfattr -n "${XATTR_PREFIX}owner" "$FILENAME" | sed -rn 's/^'"${XATTR_PREFIX}owner"'="(\w+)"\s*$/\1/p')
	FILE_MODE=$(getfattr -n "${XATTR_PREFIX}mode" "$FILENAME" | sed -rn 's/^'"${XATTR_PREFIX}mode"'="([[:digit:]]{3,4})"\s*$/\1/p')
	err=$?
	[ $err == 0 ] || exit $err
	echo "User: $FILE_OWNER, Mode: $FILE_MODE, Hash: $F_HASH"
	if [ "$F_HASH" != "$HASH" ]; then
		echo "Неправильный пароль."
		exit 68
	fi
	chown --verbose "$FILE_OWNER" "$FILENAME" | exit
	chmod --verbose "$FILE_MODE" "$FILENAME" | exit
	echo "Файл разблокирован."
fi

Для работы нужно:

1. в /etc/fstab добавить user_xattr в качестве параметра монтирования домашнего каталога

2. создать юзера у меня sshare с рабочим каталогом /home/sshare

3. поставить +t на каталог /home/sshare

4. добавить visudo строчку

u1 h1 = (root) NOPASSWD: /usr/local/sbin/sshare

5. поставить права 0700 root:root на /usr/local/sbin/sshare

вроде всё. Вот так файл блокируется:

$ sudo /usr/local/sbin/sshare testfile 
Введите пароль для шифрования 'testfile': 
Повторите пароль: 
User: u1, Mode: 1735, Hash: 4c85c02cb4611a02b6e49e801dbbbbcf
Файл защищён.

$ sudo /usr/local/sbin/sshare testfile 
Файл 'testfile' защищён, введите пароль доступа: 
User: u1, Mode: 1735, Hash: 4c85c02cb4611a02b6e49e801dbbbbcf
Файл разблокирован.

PS: это концепт. Ещё неплохо проверить каталог, в котором мы работаем. Кроме того, можно использовать няшную gxmessage, дабы вводить пароли в GUI, а не в консоли. Она вроде-бы это умеет.

Немного не понял ТЗ.

Поднять сервер и завести на нём учётки учеников, не?

Во многих классах ученикам приходится работать за одним компьютером по 2 или даже по 3.

ну мой скрипт тупо сохраняет/восстанавливает имя юзер. По идее есть смысл сделать ещё и проверку, дабы скрипт сохранял только «свои» файлы.

Спасибо, как будет время обязательно попробую.

Вам надо подумать ещё над проблемой забытых паролей. Не в том отношении, что админ/учитель может «снять» пароль — вернуть прежнее значение владельца файла, а в отношении проверки что именно этот ученик установил пароль. Наверное какая-то система, что перед началом работы они вводят свои ФИО, а учитель это подверждает...

Помнится, я в венде для подобных целей использовал запароленные нежатые архивы. Т.е. можно каждому ученику дать для файлов по такому своеобразному шифрованному контейнеру в шаре на сервере: знает пароль от такого архива - откроет файлы из него, прочитает, перезапишет; не знает/забыл - ссзб.

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

gpg --encrypt --symmetric

(кстати, сжимать полезно для криптостойкости).

ЗЫЖ в данном случае не очень, ибо учитель не сможет расшифровать то, что захочет.

Автоматизируй процесс регистрации (хоть однострочником на баше) и создавай по-нормальному по юзеру на человека храня пароли в бд. Твои костыли тебе потом поперёк и встанут.

поскольку ученики писать то еле-еле умеют.

Спецшкола?

owncloud. общую папку можно расшарить во все аккаунты. ученикам помимо пароля придется еще придумать логин при регистрации.

необходимо как-то сохранять работы каждого ученика таким образом, чтобы другие ученики того же класса не могли прочитать, изменить или удалить данные конкретного ученика

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

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

Копал бы лучше в том направлении, как это всё автоматизировать.

Спецшкола?

Нет, это сарказм... :(