Изменить разрешения для символической ссылки

37

У меня есть символическая ссылка с этими разрешениями:

lrwxrwxrwx 1 myuser myuser       38 Aug 18 00:36 npm -> ../lib/node_modules/npm/bin/npm-cli.js*

Симлинк находится в архиве .tar.gz. Теперь, когда я распаковываю архив tar.gz, используя maven, символическая ссылка больше не действительна. Поэтому я пытаюсь восстановить символическую ссылку. Сначала я создаю символическую ссылку с помощью ln, но как мне установить те же разрешения, что и у исходной символической ссылки?

symlink chmod

— U123
источник

59

Вы можете создать новую символическую ссылку и переместить ее в местоположение старой ссылки.

ln -s <new_location> npm2
mv -f npm2 npm

Это сохранит право собственности на ссылку. Кроме того, вы можете использовать, chownчтобы установить владельца ссылки вручную.

chown -h myuser:myuser npm

В большинстве систем разрешения символической ссылки не имеют значения. При использовании символической ссылки будут проверяться разрешения компонентов цели символической ссылки. Однако в некоторых системах они имеют значение. Для MacOS требуется разрешение на чтение для ссылки readlink, а sympermопция монтирования NetBSD принудительно проверяет разрешения для ссылок на чтение и обход. На этих системах (и их родственниках, включая FreeBSD и OpenBSD) есть эквивалентная -hопция chmod.

chmod -h 777 npm

— JdeBP
источник

1

Я только что столкнулся с проблемой разрешения с символическими ссылками на сервере CentOS 6.8. Символические ссылки имеют владельца: группа root: root. Когда владелец и группа были изменены на пользователя, которому принадлежал каталог, в котором они находились, как показано в этом ответе, проблема с разрешением исчезла.

— Ночная сова

Просто предоставив разъяснения. Чтобы изменить владельца или права на символьную ссылку, флаг -h будет влиять на файл символической ссылки вместо разыменованного файла.

— UltimaWeapon

12

Когда вы пытаетесь использовать chmodдля установки разрешений ссылки, на самом деле вы устанавливаете разрешения цели ссылки. Разрешения ссылки не имеют смысла.

— Просто сделай это
источник

2

Что если кто-то изменит ссылку на вредоносный код? Исходный код может даже быть чем-то, к чему root может получить доступ только. Например, в скриптах crontap.

— Аликандил

@aliqandil Обычно пользователь может удалить и воссоздать любой файл в каталоге, для которого у него есть права на запись. В bash для файла testс -rw-rw-r-- root root, для которого rm testя получаю приглашение rm: remove write-protected regular empty file 'test'?Решение состоит в том, чтобы поместить конфиденциальные файлы в каталоги, для которых пользователи имеют доступ только для чтения.

— Иногда Кашью

5

Когда у вас есть ссылка, как:

link -> foo/bar

и хочу изменить это на:

link -> new/target

Есть два случая для рассмотрения:

foo/barне является каталогом или не существует, или у вас нет доступа к поиску foo. затем
```
ln -s new/target link
```
потерпит неудачу, потому что linkуже существует, но вы можете преодолеть это, используя стандарт:
```
ln -fs new/target link
```
foo/barкаталог (и у вас есть разрешение на поиск, fooчтобы определить, что foo/barэто каталог). В том случае, когда вы делаете:
```
ln -s new/target link
```
или
```
ln -fs new/target link
```
Это понимается как создание новой targetсимволической ссылки внутри linkкаталога ( linkэто каталог, потому что это символическая ссылка на foo/barкаталог). Итак, вы на самом деле создадите:
```
foo/bar/target -> new/target
```
Чтобы преодолеть это, в GNU lnесть -Tвозможность, чтобы имя ссылки всегда рассматривалось как имя ссылки, а не как каталог для создания ссылки (ей). Итак, с GNU ln:
```
ln -fsT new/target link
```
буду работать. Как и раньше, он удалит исходную linkсимволическую ссылку и создаст ее заново, new/targetуказав в качестве цели (а также euid и egid процесса в качестве владельца).

У GNU lnтакже есть -nопция. Он работает так, -Tза исключением случаев, когда linkфактически является реальным каталогом, и в этом случае он все равно будет создавать символическую ссылку внутри этого каталога (вместо сбоя с ошибкой).

Как правило, лучше всего сначала удалить ссылку, а затем воссоздать ее:
```
rm -f link && ln -s new/target link
```

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

В системах, где разрешения символической ссылки имеют значение (например, OS / X, где вам нужно разрешение на чтение символической ссылки, чтобы иметь возможность разрешить ее цель), обычно есть способ изменить их ( chmod -hв OS / X).

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

chown -h user[:group] the-link
chgrp -h group the-link

— Стефан Шазелас
источник

0

Если вам действительно нужно изменить разрешение символических ссылок (как правило, бессмысленно, как написано в других ответах), я успешно использовал -Rпараметр chown:

chown -R myuser:mygroup link

Если -Rне был использован, разрешения не были изменены.

— Мирослав Мочек
источник

Это будет работать с GNU, chownпотому что -Rподразумевается -Pтам, однако это не гарантировано и не будет работать в некоторых других реализациях chown. Стандартный способ изменить владельца символической ссылки с помощью -hопции. Я только что обновил принятый ответ, который был неверным.

— Стефан Шазелас