«cannot open shared object file: No such file or directory»

«Владелец» это кто? У него вероятно где-то какие-то спец. настройки прописаны, иначе не будет работать (то есть дело не в том что он владелец а в чём-то другом). Библиотеки, просто положенные рядом, без LD_LIBRARY_PATH=. подтягиваться не будут никак. Может у «владельца» как раз LD_LIBRARY_PATH где-нить в $HOME/.profile и прописан.

https://www.pluralsight.com/blog/it-ops/linux-file-permissions

«Владелец» это кто?

Тот, чьё имя ls -l выводит 3-ей слева колонке. И в чьей домашней директории всё происходит. GCC запускался от его же имени, но не для всех программ.

У него вероятно где-то какие-то спец. настройки прописаны

$ echo \'$LD_LIBRARY_PATH\'
''

Никаких LD нет ни в ~/.profile, ни в ~/.bashrc.

https://www.pluralsight.com/blog/it-ops/linux-file-permissions

Пока ничего нового.

chown -R user1:user2 ~/compiled_program/
chmod -R g+rw ~/compiled_program/
chmod g+x ~/compiled_program/a.out
cd ~/compiled_program/
su user2
./a.out

Чтобы решить проблему с «владельцем», проведи такой эксперимент: скопируй директорию с бинарником и библиотеками в $HOME новосозданного юзера, смени там владельца на него же и попробуй от него запустить. Я думаю будет ошибка.

А потом (после первого теста, вне зависимости от результатов), сделай ldd на бинарник (который то запускается то нет) сначала владельцем а потом не владельцем.

Кажется, локализовал. RHEL7. Стабильно не работает, когда user2 не может читать /home/user1 Даже когда имеет все права на /home/user1/compiled_program/

скопируй директорию с бинарником и библиотеками в $HOME новосозданного юзера, смени там владельца на него же и попробуй от него запустить. Я думаю будет ошибка.

Отработало нормально. Даже без смены владельца.

А потом (после первого теста, вне зависимости от результатов), сделай ldd на бинарник (который то запускается то нет) сначала владельцем а потом не владельцем.

На бинарник – всё совпало. А вот когда начал перебирать библиотеки, нашёл различие:

user1: libparse.so.1 => //home/user1/compiled_program/./libparse.so.1

user2: libparse.so.1 => not found

Все остальные строки – вида libc.so.6 => /lib64/libc.so.6 (0x00007fa007c2f000)

То есть в чём проблема? Не удаётся прочитать каждую поддиректорию от корня до целевого файла? Зачем вообще это нужно?

На бинарник – всё совпало. А вот когда начал перебирать библиотеки, нашёл различие:

Что совпало? Надо ввести

ldd executable_file_name

и сравнить вывод от разных юзеров. По-моему ты это и сделал дальше, нашёл отличие в оной из строчек.

libparse.so.1 => //home/user1/compiled_program/./libparse.so.1

Без LD_LIBRARY_PATH такое кажется невозможно.

user2 не может читать /home/user1 Даже когда имеет все права на /home/user1/compiled_program/

Как он попал в /home/user1/compiled_program/ если не можжет попасть в /home/user1 ?

Без LD_LIBRARY_PATH такое кажется невозможно.

Пусто у обоих. Поэтому и создал тему.

На всякий случай: эта библиотека компилировалась Free Pascal-ем.

Как он попал в /home/user1/compiled_program/ если не можжет попасть в /home/user1 ?

Через su user2 от имени user1.

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

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

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

Поскольку сложно проконтролировать, чтобы все обращения были строго по относительному пути, то ситуация «Через su user2 от имени user1.» с попаданием туда, куда user2 сам по себе бы не попал - в любом случае чревата проблемами. Но если весь исполняемый там код, включая код динамического линкера, написан (или проверен построчно) тобой и ты точно знаешь, что он делает - то так можно делать.

Пусто у обоих. Поэтому и создал тему.

Может то же самое можно настройками линкера сделать (у меня они в /etc/ld.so.conf). Ну или в конце концов может линкер патченый.

ты звезд-то откуда нахватал?

Не удаётся прочитать каждую поддиректорию от корня до целевого файла? Зачем вообще это нужно?

Не прочитать, а пройти(traverse). За это отвечает executable bit(+x в chmod). Подробности тут. Что позволяет делать директории в которых ты не можешь смотреть содержимое(потому что за это отвечает +r), но можешь перейти в них и ниже(если знаешь имя нижележащей директории).

Тут вам не здесь^W Windows, где пользователь, знающий про пусть вида disk:\no_perm_dir\some_dir и имеющий на some_dir права сможет попасть в эту директорию. POSIX права строго иерархичны и необходимо иметь какой-либо минимальный уровень прав на вышестоящую директорию(тот самый executable bit, который для файлов разрешает их выполнение) для того чтобы попасть в нижестоящую

Тут вам не здесь^W Windows, где пользователь, знающий про пусть вида disk:\no_perm_dir\some_dir и имеющий на some_dir права сможет попасть в эту директорию. POSIX права строго иерархичны и необходимо иметь какой-либо минимальный уровень прав на вышестоящую директорию(тот самый executable bit, который для файлов разрешает их выполнение) для того чтобы попасть в нижестоящую

Нет. Хотя может ты и пытался донести правильную мысль, но всё переврал в итоге.

Буду рад, если ты меня аргументированно поправишь.

mini-router [~]$ whoami
pinkbyte
mini-router [~]$ ls -lad 1
drwx--x--x    3 root     root            60 Dec  1 22:07 1
mini-router [~]$ ls -la 1/
ls: can't open '1': Permission denied
total 0
mini-router [~]$ ls -la 1/2
total 0
drwxr-xr-x    2 pinkbyte wheel           40 Dec  1 22:07 .
drwx--x--x    3 root     root            60 Dec  1 22:07 ..
[.code]

Права не иерархичны. Просто (наглядно) чтобы пройти по пути с множеством ворот, они все должны быть открыты, а не только последние. Когда же ты какие-то ворота уже прошёл, они могут сколько угодно закрываться и на дальнейший путь уже не влияют. Более того, даже «дорога» сзади может переделываться на лету - ты перешёл в /home/user/dir1, затем кто-то (с рут правами) сделал mv /home/user/dir1 /root/dir1 и ты оказался в /root/dir1, хотя в /root ты не входил и права на доступ к нему нигде не предъявлял и никто их у тебя не спросит.

Хм, возможно я не тот смысл вкладывал в слово «иерархичны», виноват. Скорее всего наложился тот факт, что в POSIX ACL как правило они как раз иерархичны(при эксплуатации в 90% случаев используется наследование, но можно при желании отключить/не включать, да).

Принято

Не прочитать, а пройти(traverse). За это отвечает executable bit(+x в chmod).

Точно! В Fedora 30 /home/user1/ имеет rwx------, и в нём не заработало, пока не сделал rwx--x---.

Спасибо.