Существует ли стандартная символическая ссылка на домашний каталог текущих пользователей?


9

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

У меня были конфигурационные файлы, где $HOMEработает, но ~не работает , и наоборот.

Я думаю, что предохранитель может обеспечить что-то в этом роде, что-то вроде /var/myself->$HOME

С этим я мог бы поместить значения в конфигурационные файлы, чтобы указать на такие вещи, как /var/myself/backdrops/pornography/wtf/yarly.jpg

Уже есть что-то подобное? Если нет, есть ли веские причины для того, чтобы этого не происходило?


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

Ответы:


6

Я понимаю ваше беспокойство, но ответ «нет», такого нет.
Обычный метод - задать ОС домашний путь пользователя или получить переменную $ HOME.

Все эти опции всегда нуждаются в некотором кодировании из приложения. Многие приложения, такие как bash, предлагают «псевдоним» ~ (open (2) не переводит это).

Конечно, для этого может быть реализован модуль vfs или fuse. Наверное, есть что сделать, я собираюсь спросить!

Но действительно ли это нужно? Вы можете использовать обходной путь, как:

  • Создайте сценарий для запуска программы, которая связывает $ HOME с относительным путем или известным местоположением.

  • Используйте pam_exec, чтобы связать каталог $ HOME с известным местоположением http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_exec.html


Я прошу инструмент vfs: unix.stackexchange.com/questions/1811/…
Keymon

0

Одна хитрость (по крайней мере, в Linux) состоит в том, чтобы изменить каталог $HOMEдо запуска приложения и затем использовать его /proc/self/cwd/...в файле конфигурации.


Мне нравится хакерство этого, но, вероятно, оно столкнется с проблемами, если процесс изменит текущий каталог. Я хотел бы / proc / PID / iwd для начального рабочего каталога.
Lerc

... и в этом отношении / proc / PID / home
Lerc

@Lerc, если это происходит в файле конфигурации он должен быть /proc/selfне /proc/PID, так как вы не можете знать заранее , что PID будет.
Нил Мэйхью

@Lerc, да, если процесс изменит каталог, то произойдет сбой, но обычно программы читают файл конфигурации один раз при запуске, а затем кэшируют значения в памяти. Все зависит от программы, с которой вы работаете, и если программа не обладает достаточной гибкостью, будь то в командной строке или в синтаксисе файла конфигурации, вы застряли.
Нил Мэйхью

Да, я имел в виду, что / proc / PID / home означает, что все каталоги proc / PID должны поддерживать это и, следовательно, включать / proc / self
Lerc

0

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


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

0

Вы можете получить pid запроса пользователя и спросить систему его / ее домашнего каталога. Так что можно.

Однако я не уверен, что нет программ SUID, которые бы воспринимали FS как статический.

Редактировать:

struct fuse_context *ctx = fuse_get_context ();
struct passwd pwd, *ppwd;
char buffer[1024];
int status = getpwuid_r (ctx->ui, &pwd, buffer, sizeof(buffer), &ppwd);
if (status == 0) {
  if (ppwd == NULL) {
    // No record found
  } else {
    // Handle record
  }
} else {
    // Handle error
} 

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


Как бы вы нашли его домашнюю директорию после того, как узнали, что это за пользователь?
WhyNotHugo

Используя getpwuidили getpwuid_r.
Мацей Пехотка
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.