Скрыть от пользователя системные разделы?

[GSMD]

Т.е. чтобы после входа пользователь не видел раздел "/" и прочие, которые ему не нужны, только один раздел, в котором будут храниться его документы. Возможно ли такое?
Спасибо.

[KiWi]

зачем?

[t.t]

Э.. а можно вопрос? Если пользователь не будет видеть ничего за пределами ~, то как у него вообще что-то работать будет? Без /etc, /bin, /usr и т.д.

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

[KiWi]

да вообщем как раз +x с директорий, ИМХО, надо и снять -- он как раз и отвечает за получение листинга

[sergius]

ИМХО, GSMD имел ввиду другое - дать пользователю его десктоп. И чтобы он, открывая файловый менеждер не видел директории, кроме домашней.

[GSMD]

IFL
Попробую, спасибо.

sergius
Да, где-то так.
Идея в том, чтобы юзер видел только свои документы, а системные файлы оставались "за кадром".
Аналогия, приходящая на ум: запрет листинга на ftp, когда можешь скачать файл только точно зная его расположение и имя.

[bobrik]

Решили лишить пользователей приемуществ???
ФМ и так хомяка по умолчанию открывает

[sedition]

А если поместить пользователя в chroot?

[t.t]

да вообщем как раз +x с директорий, ИМХО, надо и снять -- он как раз и отвечает за получение листинга

↑

Проверил бы прежде чем говорить. Бит исполнения на каталоге отвечает за доступ к файлам в нём, а вот бит чтения -- как раз за листинг; т.к. содержимое "файла каталога" -- это и есть список файлов в нём.

Аналогия, приходящая на ум: запрет листинга на ftp, когда можешь скачать файл только точно зная его расположение и имя.

↑

Так это и есть отсутствие бита чтения на каталоге.

А если поместить пользователя в chroot?

↑

Вот тогда уж точно он доступа к системным файлам иметь не будет.

[WarlorD]

да вообщем как раз +x с директорий, ИМХО, надо и снять -- он как раз и отвечает за получение листинга

↑

Проверил бы прежде чем говорить. Бит исполнения на каталоге отвечает за доступ к файлам в нём, а вот бит чтения -- как раз за листинг; т.к. содержимое "файла каталога" -- это и есть список файлов в нём.

Аналогия, приходящая на ум: запрет листинга на ftp, когда можешь скачать файл только точно зная его расположение и имя.

↑

Так это и есть отсутствие бита чтения на каталоге.

А если поместить пользователя в chroot?

↑

Вот тогда уж точно он доступа к системным файлам иметь не будет.

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

[t.t]

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

↑

Это только в том случае, если предположить полное отсутствие в системных скриптах масок по имени файла в системных же каталогах, т.е. _только_ прямое обращение по _точным_ именам файлов. Я не уверен, что это так.

[WarlorD]

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

↑

Это только в том случае, если предположить полное отсутствие в системных скриптах масок по имени файла в системных же каталогах, т.е. _только_ прямое обращение по _точным_ именам файлов. Я не уверен, что это так.

да и впрямь, неподумал про это, видать и правда не панацея

[susik]

А что если сделать chroot и создать необходимые каталоги и скопировать всякие ls и т.д
Так работать будет только надо точно знать что нужно будет пользователю.
Вообще если спросить у google то я думаю такую проблему еже решали и не раз.

[t.t]

А что если сделать chroot и создать необходимые каталоги и скопировать всякие ls и т.д

↑

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

А ещё интересно было бы всё-таки услышать от автора темы ответ на этот вопрос:

зачем?

↑

[polachok]

вам в GoboLinux (вроде так пишется, поправьте если не прав)

[t.t]

вам в GoboLinux

↑

А что, там есть такое? Не знаешь, как реализовано? Просто интересно.

[GSMD]

t.t
Ответ на вопрос "Зачем?"
Есть программный продукт, поставляемый клиенту вместе с операционной системой. Пользователь - офисный работник, которому нужна от компьютера весьма ограниченная функциональность. Соответственно, все должно быть очень просто, и ничего лишнего не "торчать".

[WarlorD]

t.t
Ответ на вопрос "Зачем?"
Есть программный продукт, поставляемый клиенту вместе с операционной системой. Пользователь - офисный работник, которому нужна от компьютера весьма ограниченная функциональность. Соответственно, все должно быть очень просто, и ничего лишнего не "торчать".

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

[t.t]

t.t
Ответ на вопрос "Зачем?"
Есть программный продукт, поставляемый клиенту вместе с операционной системой. Пользователь - офисный работник, которому нужна от компьютера весьма ограниченная функциональность. Соответственно, все должно быть очень просто, и ничего лишнего не "торчать".

↑

А может не надо прибирать всё? Закрыть доступ на чтение на / и /home (дабы через .. не попасть), а на всё остальное -- токмо на запись? С одной стороны, вряд ли системные скрипты перебирают по маске содержимое корня; а с другой -- обычный пользователь, не имея доступа к тому же корню, вряд ли долезет до /etc или /usr, особенно если не устанавливать терминалов, убрать все консоли кроме первой и лочить её после запуска иксов.

[polachok]

2t.t: понятия не имею как, но сделано. Читать http://posix.ru/distro/gobolinux/ тут

root@NewMachine ~]ls /
Depot Files Mount Programs System Users
root@NewMachine ~]ls -a /
. .. Depot Files Mount Programs System Users
root@NewMachine ~]ls -ld /bin /dev /etc /home /lib /proc /root /sbin
ls: /home: No such file or directory
ls: /root: No such file or directory
lrwxrwxrwx 1 root root 25 2005-11-08 15:44 /bin -> System/Links/Executables
lrwxrwxrwx 1 root root 22 2005-11-08 15:44 /dev -> System/Kernel/Devices
lrwxrwxrwx 1 root root 16 2005-11-08 15:44 /etc -> System/Settings/
lrwxrwxrwx 1 root root 23 2005-11-08 15:44 /lib -> System/Links/Libraries
lrwxrwxrwx 1 root root 21 2005-11-08 15:44 /proc -> System/Kernel/Status
lrwxrwxrwx 1 root root 25 2005-11-08 15:44 /sbin -> System/Links/Executables
root@NewMachine ~]mkdir /etc
root@NewMachine ~]ls -ld /etc
lrwxrwxrwx 1 root root 16 2005-11-08 15:44 /etc -> System/Settings/
root@NewMachine ~]rm /etc
rm: remove symbolic link `/etc'?


Интересно? При этом с любого LiveCD в файловой системе корневого раздела GoboLinux видны симлинки /bin, /dev, /etc, /home, /lib, /proc, /root и /sbin, что наталкивает на мысль, что разработчики грубо спрятали эти симлинки поимённо.

вот еще: http://gobolinux.org/?page=doc/articles/gobohide рекомендую!

[t.t]

2polachok: это тоже не совсем то: если ставить именно GoboLinux, то он просто подменяет сущности, а не прячет их. А если использовать gobohide в другом дистре по своему усмотрению, то это, насколько я понял, не избавляет от упомянутой проблемы с поиском по маске.