ГПСЧ не загружен (в SCO OpenServer 5.0.7 MP5)
Ответ bodhi.zazen правильный, но я хотел бы ответить на него немного по-другому: разрешения прикрепляются к индексу, а символическая ссылка и ее цель имеют каждый свой собственный индекс. Рассмотрим проблемы foo и , ниже:
$ ls -l foo issues
lrwxrwxrwx 1 jklowden jklowden 6 Feb 18 16:46 foo -> issues
-rw-rw-r-- 1 jklowden jklowden 2380 Jan 29 14:02 issues
$ stat foo
File: ‘foo’ -> ‘issues’
Size: 6 Blocks: 0 IO Block: 4096 symbolic link
Device: 811h/2065d Inode: 11406493 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 1000/jklowden) Gid: ( 1000/jklowden)
Access: 2016-02-18 16:46:52.224805576 -0500
Modify: 2016-02-18 16:46:40.905398163 -0500
Change: 2016-02-18 16:46:40.905398163 -0500
Birth: -
$ stat issues
File: ‘issues’
Size: 2380 Blocks: 8 IO Block: 4096 regular file
Device: 811h/2065d Inode: 11405468 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/jklowden) Gid: ( 1000/jklowden)
Access: 2016-01-29 14:05:26.122808636 -0500
Modify: 2016-01-29 14:02:52.106866058 -0500
Change: 2016-01-29 14:02:52.106866058 -0500
Birth: -
Обычно права доступа к файлу определяют, что вы можете с ним делать, но, как это происходит в большинстве систем, разрешения на файл символической ссылки ничего не контролировать. (Вы можете chmod 0 foo , и по-прежнему работает ln -sf foo bar .) Здесь учитываются разрешения на индексном дескрипторе 11405468.
[Нижеследующее исправлено. Спасибо dave_thompson_085 за его поясняющий комментарий.]
В вашем примере реальный файл (а не символическая ссылка), конечно, f3-w.log . Поскольку он принадлежит вашей группе, dkanagaraj, и имеет права чтения группы, вы ожидаете, что сможете читать его содержимое, независимо от того, какую символическую ссылку вы использовали.
Права на чтение файла также контролируются путем к нему. При доступе к файлу требуется разрешение на выполнение для всех каталогов, перечисленных в имени пути. ( Интерфейс программирования Linux , раздел 15.4.3, стр. 297). Поскольку символическая ссылка использует абсолютный путь к своей цели, группе dkanagaraj требуется разрешение на выполнение для каждого компонента имени пути: / , home , dkanagaraj и .forever . Ограничение разрешения пути применяется к любому файлу, включая саму символическую ссылку, но я думаю, что вы это покрыли.
Разрешение стало возможным благодаря поиску в различных частях системы экземпляров prng без учета регистра -.
Предварительное исследование показало, что на системах с одинаковой конфигурацией, но там, где одна работает, а другая нет, конфигурация кажется идентичной, но на неработающей -системе службаin.prngdне бегать.
# ps -ef | grep prng
root 350 1 0 Mar-23 ? 00:00:11 /etc/in.prngd /etc/egd-pool
Между обеими системами файлы конфигурации, сценарии и двоичные файлы, в или ниже/etc , по-видимому, связанные с prngd , имеют одинаковые суммы, и проверка системного программного обеспечения не показывает автоматически исправимых аномалий..
Сценарии запуска в/etc/rc?.d/были идентичными, с prngd запуск, очевидно, обрабатывался/etc/rc2.d/S85tcp. Проверка этого файла показывает, что служба запускается вызовом/etc/prngd , а/var/adm/rc.logпоказывает, что система пыталась запустить службу..
Starting TCP services: prngd inetd snmpd sshd ntpd
Попытка вручную использовать/etc/prngdдля запроса или запуска службы завершается с аналогичной ошибкой:
# /etc/prngd query
/etc/prngd: ^X: bad number
Была сделана копия/etc/prngd , и набор -x вставлен:
...
+ get_server_pid
+ [ -r /etc/prngd.lock ]
+ read line
+ set -- junk
+ shift
+ return
/tmp/prngd: ^X: bad number
В рабочей системе/etc/prngd.lockне -пуст и содержит PID запущенного процесса in.prngd. В нерабочей системе -файл пуст.
Решение:
# rm -f /etc/prngd.lock