Является неправильным chmod поведение при символьных ссылках?

Создание символьных ссылок на двоичные файлы прекрасно; проверить /bin и /usr/bin и Вы почти наверняка найдете много псевдонимов. Проблема здесь использует sudo полностью не понимая последствий. К счастью, не было никакого постоянного вреда, и Вы извлекли важный урок. Когда Вы просто удостоверяетесь, что они - исполняемый файл, используют a+x или даже u+x вместо этого. Как uther говорит, Вы, вероятно, были бы более обеспечены с псевдонимом так или иначе.

Сама страница справочника объясняет, почему это - действие - полномочия на символьных ссылках не имеют значения, только на файлах, они разрешают. Как правило, пользователь действительно хочет изменить атрибуты файла, на который указывает ссылка.

Кроме того, я просто проверил chmod() страницы справочника syscall для Linux и BSD. Они оба возвращают ошибки для циклов символьной ссылки, подразумевая, что это поведение изменения перманента файла а не ссылка определяется и осуществляется на уровне ядра.

Я соглашаюсь, что это не имеет большой смысл при размышлении о символьной ссылке как о символьной ссылке.

Но если Вы думаете о символьной ссылке как о том, чтобы быть похожем на жесткую ссылку, оно имеет больше смысла.

Первая строка man 7 symlink говорит точно это

Symbolic links are files that act as pointers to other files. 
To understand their behavior, you must first understand how hard links work.

A hard link to a file is indistinguishable from the original file because
it is a reference to the object underlying the original filename.
[...]
Changes to a file are independent of the name used to reference the file. 

Так, с жесткой ссылкой при изменении полномочий на файле через любое имя базовые полномочия изменяются для всех имен.

Большинство инструментов пытается следовать за символьными ссылками, так, чтобы можно было притвориться, что это - действительно жесткая ссылка.

Except as noted below, commands follow symbolic links named as
command-line arguments.

The mv(1) and rm(1) commands do not follow symbolic links named as
arguments, but respectively attempt to rename and delete them. 

Commands traversing a file tree [...]

Создание символьных ссылок (или жесткие ссылки) к двоичным файлам иногда полезно, но поскольку Вы просто обнаружили, оно действительно создает некоторые угловые случаи, которые могли вызвать проблемы.

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

Если у другого пользователя, как предполагалось, был доступ для чтения к Вашему ~/bin, затем sudo было абсолютно ненужным.

Или если у них не было доступа, Вы, возможно, предоставили его (например, использование chmod g+rx $HOME/bin), или предоставил им tarball.

Если Вы все еще думаете с помощью sudo хорошая идея, вот несколько альтернатив:

sudo chown -h $USER $HOME/bin/*
chmod 755 $HOME/bin/*

-h говорит chown не следовать за символьными ссылками

chmod -R 755 $HOME/bin/*

-R говорит chmod "пересекать дерево файла", которое заставляет его проигнорировать символьные ссылки, как намекнули выше в man 7 symlink.

sudo find $HOME/bin/ -type f -exec chmod 755 {} +

-type f говорит find не выполнять исполнительную команду (в этом случае chmod) на символьных ссылках.

# as user 2
cd ~user2/bin
sudo tar -C ~user1/bin -cf - . | tar -xf -

выполнения tar -cf как базируются, таким образом, Вы видите любые файлы, но выполнения tar -xf как user2, который заставляет извлеченные файлы принадлежать user2.

Mikel уже сказал это, но это отчасти прокладывается под землей в его ответе, таким образом: реальная вещь, которая была сделана неправильно,

sudo chmod 755 $HOME/bin/*     # <<<< highly suspicious!

Довольно странно нуждаться в полномочиях суперпользователя действовать на файлы в корневом каталоге. Если парень нашел, что у него не было полномочий сделать что-то в его собственном корневом каталоге, он должен был исследовать ситуацию и не вслепую выполнить sudo. Повторить: вслепую не выполняйте sudo. Если парень имел, работал chmod 755 $HOME/bin/*, затем он видел бы сообщение об ошибке chmod: changing permissions of/home/guy/bin/s': Операция, не разрешенная'.

Между прочим, я не рекомендую делать s псевдоним для sudo (и если необходимо сделать это, я рекомендую использовать псевдоним оболочки и не символьную ссылку: нет никакого смысла на это имя, являющееся доступным сценариям). sudo не мягкая операция, можно позволить себе ввести три дополнительных символа при выполнении ее. При предоставлении ему псевдоним с одним символом увеличивает риски опечаток.

Это - немного удивления это chmod действия на цели символьных ссылок, когда большинство операций на метаданных действует на саму ссылку. Однако символьные ссылки не имеют никаких полезных полномочий: они никогда не пишутся (только созданный и перезаписанный) или выполняются, и редко существует любая точка к сокрытию их цели. Варианты Unix отличаются относительно ли chmod символьные ссылки влияния (не поддерживаемый всеми системами), их цель или ни один. На Linux, chmod влияет на цель.

Создание псевдонима и создание символьной ссылки на файл оба допустимы (хотя псевдонимы обычно предпочитаются). Я не думаю, что в этой ситуации существует "отказ". Это - поведение chmod, таким образом, теперь Вы знаете как chmod работы над symlinked файлами (это не изменилось) и могут постараться не делать это в будущем. Если это действительно происходит снова, Вы знаете, как зафиксировать его.