Intereting Posts

Использование autofs для монтирования под домашним каталогом каждого пользователя

(крестовый поход от SF, где я не получал много радости)

У меня есть окно CentOS 6.2 и работает и настроил autofs, чтобы авторизовать общие папки Windows в папке / mydomain, используя различные howtos в Интернете. В частности, у меня есть три файла:

/etc/auto.master

# ... /mydomain /etc/auto.mydomain --timeout=60 # ... 

/etc/auto.mydomain

 * -fstype=autofs,-DSERVER=& file:/etc/auto.mydomain.sub 

/etc/auto.mydomain.sub

 * -fstype=cifs,uid=${UID},gid=${EUID},credentials=${HOME}/.smb/mydomain ://${SERVER}/& 

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

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

  1. Настройте autofs так, чтобы монтирования были локальными для каждого пользователя, но по одному пути, поэтому каждый из них может одновременно получать доступ /mydomain/server1 со своими учетными данными
  2. Настройте autofs, чтобы точки монтирования находились в домашней папке каждого пользователя, поэтому каждый из них может одновременно обращаться к ~/mydomain/server1 со своими учетными данными
  3. Настройте autofs, чтобы подставки находились под папкой с именем пользователя, поэтому они могут одновременно обращаться /mydomain/$USER/server1 со своими учетными данными (но мне также необходимо убедиться, что /mydomain/$USER составляет 0700 для данного $ USER)

До сих пор я не вижу никакого способа сделать # 1, но для # 2 или # 3 я попытался изменить запись в /etc/auto.master, так что ключ будет либо ${HOME}/mydomain либо /mydomain/${USER} , но ни одна из них не работала (первый не показал совпадающей записи в /var/log/messages а второй, похоже, не выполнял замену переменных).

Мне что-то не хватает?

(PS: Бонусные реквизиты, если вы можете предоставить возможность избежать необходимости использования файла учетных данных с открытым текстом – может быть, прямое приглашение для имени пользователя / домена / пароля или, возможно, даже магия kerberos?)

(PPS: Я кратко посмотрел на smbnetfs , но я не смог его настроить / сделать – он запрашивает fuse >= 2.6 хотя у меня есть v2.8.3 в соответствии с fusermount --version – и я не мог найти выпущенную версию для yum install )

(PPPS: Я также кратко рассмотрел предоставленный /etc/auto.smb но похоже, что он будет /etc/auto.smb те же проблемы с совместным использованием?)

Я много работал с autofs и монтировал множество различных типов ресурсов. Вы можете проверить man-страницу для autofs которая отвечает на некоторые ваши вопросы, если вы можете прямо autofs что, когда они ссылаются на $USER в документации, они ссылаются на пользователя, который запускает демон autofs . Это переменные, которые вы получаете по умолчанию:

 Variable Substitution The following special variables will be substituted in the key and location fields of an automounter map if prefixed with $ as customary from shell scripts (Curly braces can be used to separate the field name): ARCH Architecture (uname -m) CPU Processor Type HOST Hostname (uname -n) OSNAME Operating System (uname -s) OSREL Release of OS (uname -r) OSVERS Version of OS (uname -v) autofs provides additional variables that are set based on the user requesting the mount: USER The user login name UID The user login ID GROUP The user group name GID The user group ID HOME The user home directory HOST Hostname (uname -n) Additional entries can be defined with the -Dvariable=Value map-option to automount(8). 

Вероятно, у вас -DUSER=$USER соблазн использовать -DUSER=$USER но это только установит $USER внутри autofs карты autofs для пользователя, который запустил демон autofs . Демон обычно принадлежит пользователю, например root или chrooted пользователю, специально настроенному для autofs .

ПРИМЕЧАНИЕ №1: файл autofs состоит из key и value . Переменные допускаются только для использования в пределах value элемента записи.

ПРИМЕЧАНИЕ # 2: Если переключатель -D=... не переопределяет встроенную переменную, тогда $USER или $UID будут содержать значение $USER & $UID , которое обращается к монтированию.

Ограничение доступа к ресурсу CIFS

Что касается вашего вопроса о том, как ограничить доступ к монтированию CIFS , я не вижу способа выполнить это с помощью autofs .

Учетные данные, используемые для монтирования CIFS ресурса CIFS , используются на протяжении всего времени, когда этот ресурс монтируется. По сути, autofs , запускающий его daemon automount как say root , «эквивалентен» autofs данным пользователя CIFS .

Это не то, что я считаю типичным поведением для autofs и является побочным продуктом использования mount.cifs . Типичное поведение autofs будет уважать разрешения на другом конце монтирования, тогда как с mount.cifs это не так.

Нижняя линия

Я думаю, вам не повезло, выполнив настройку с помощью autofs. Я думаю, вам придется использовать fuse если вы действительно хотите, чтобы каждый пользователь CIFS доступ к CIFS ресурсам CIFS используя свои собственные учетные данные.

Использование Samba:

В /etc/auto.home :

 * -fstype=cifs,credentials=/etc/smbcreds.& ://MYSERVERIP/homes 

Вам нужно будет хранить всех пользователей и пароли в независимом файле /etc/smbcreds

Последняя часть линии будет монтироваться через самбу.

Использование NFS:

В /etc/auto.home: (для NFS)

 * MYSERVERIP:/home/& 

Вы можете принудительно установить разрешения, установленные на монтировании CIFS, с параметрами file_mode и dir_mode в сочетании с настройкой uid=${USER} вы уже использовали, предоставив автоматную строку следующего типа:

 * -fstype=cifs,uid=${UID},gid=${EUID},file_mode=0600,dir_mode=0700,credentials=${HOME}/.smb/mydomain ://${SERVER}/& 

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

Возможно, вы захотите установить file_mode=0700 если есть исполняемые файлы, которые, как вы ожидаете, смогут запускаться на общем ресурсе. Мой пример удаляет разрешение на выполнение, поскольку это было поведением, которое я хотел.

Примечание. Этот вариант, возможно, не существовал в тот момент, когда был задан вопрос, но он делает это сейчас!