View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003344 | Far Manager | Command Line/Execute | public | 2016-11-09 13:40 | 2016-11-11 19:27 |
Reporter | heilong | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Summary | 0003344: Feature: Добавить опцию не искать исполняемые файлы в текущей директории | ||||
Description | В первую очередь, это огромная дыра в безопасности. Думаю, объяснять не надо. Во всех UNIX-ах настоятельно не рекомендуется иметь "." в Path. Если и разрешать ".", то только непривилегированным юзерам, и обязательно в конец Path-а. Если есть нужда выполнить что-то из текущей директории, пишется явно: ./file Во-вторых, есть и просто неудобства. Если у меня в Path есть file.exe, а в текущей директории оказался ненароком файл file (без расширения), и в командной строке набрать file <Enter>, то Фар попытается исполнить file из текущей директории. Мне хотелось бы иметь возможность вообще не рассматривать текущую директорию для поиска исполняемых файлов. Пожалуйста, добавьте такую опцию. | ||||
Tags | No tags attached. | ||||
Build | |||||
|
> Если есть нужда выполнить что-то из текущей директории, пишется явно: ./file Каждый раз, когда я вижу "command not found", мне хочется найти автора этой фичи и пожать ему горло. Но это так, лирическое отступление. У вас же, насколько я помню, свой комспек, и, предполагаю, он и так уже не ищет, так в чём проблема? |
|
Про "command not found" это с непривычки, первое время, когда Linux изучал, тоже доставало иногда. Но как привычка выработалась, никакого неудобства более не доставляет. Ведь это реально дыра в безопасности, иначе никак с этим не побороться. Про комспек всё верно. Но я всё-таки позволяю Фару выполнять простые команды direct run-ом из соображений оптимизации. Не хотелось бы из-за этой темы ставить ComspecCondition `.*`. Полагаю, что Windows-пользователи юзать запрошенную мною опцию не станут, а меня лично бы устроил просто boolean flag в far:config. Вот такую, кстати, фигню записываю в ComspecCondition: -- Use comspec (bash) if command line contains: -- - `\` followed by a single character from the list `'"\` -- - `$` not within single quotes -- - A single character from the list `[({;<>|&` not within single or double quotes local comspecCondition_bash = "(?:\\\\['\\\"\\\\]|^(?:(?:[^']|'[^']*')*?\\$|(?:[^\\\"']|\\\"[^\\\"]*\\\"|'[^']*')*?[[({;<>|&]))" |
|
Может и дыра, но бороться с этим в отдельно взятом фаре не очень продуктивно. У меня на XP такого нет. |
|
Я c cmd.exe вообще не работаю. Остаётся только bash и Far (когда он использует direct run). Полагаю, некоторые используют только Far с cmd/tcc/powershell, а не оные в простой консоли? Так что в рамках Фара бороться с этим весьма продуктивно (пусть и не на 100%). Если думать о красоте и предсказуемости - поведения фара в режиме direct run должно максимально совпадать с выполнением той же команды через comspec. В случае (comspec == cmd) логично оставить старое поведение, т.е. искать в текущей директории. Но вот в моём случае (comspec == bash) bash файл в текущей дире не ищет, стало быть и Фар пусть не ищет. По логике direct run / comspec run должны быть взаимозаменяемы, первый присутствует лишь для оптимизации. Я прошу лишь добавить far:config опцию для этой фичи. Не думал, что ещё кто-то XP пользуется :) В Windows 7 это так. Об этом я отдельный багрепорт / wish написал. http://bugs.farmanager.com/view.php?id=3345 |
|
Мне как-то Давайте так: сейчас поиск в PATH написан несколько криво, если его слегка улучшить, то по умолчанию фар всё так же будет искать сначала в curdir, а потом в PATH, однако, если вы из плагина или скрипта сделаете SetSearchPathMode(BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE) (или включите его глобально в реестре) - фар будет сначала искать в PATH, и только если ничего не нашлось - в curdir. |
|
Понял. Не возражаю против такой опции. А можно ли добавить ещё один режим, в котором curdir ну совсем не юзается? upd: Не увидел сразу, что это Виндовая встроенная функция. Всё-таки, как-либо я смогу убрать . из пути поиска? |
|
> Всё-таки, как-либо я смогу убрать . из пути поиска? Нет, т.к. ShellExecute / CreateProcess всё равно ищут в текущей папке. |
|
Ну ладно, хотя бы отправить . в зад это уже большое дело. Буду весьма благодарен. Про реестр имеется в виду HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SafeProcessSearchMode -> 1 ? https://msdn.microsoft.com/en-us/library/windows/desktop/aa365527(v=vs.85).aspx |
|
Я поигрался и там не всё так просто - оно в таком режиме использует только системный %path%, игнорируя пользовательский, что нам не подходит. |
|
Хотя, в принципе, если вас устраивает следующий порядок: По умолчанию: текущий каталог, системные каталоги, %path% SetSearchPathMode(BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE): системные каталоги, текущий каталог, %path% - то могу сделать. |
|
Лично я не юзаю User Path вообще. Все мои пути - в System Path. В этом случае будет ли SetSearchPathMode(BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE)? системные каталоги (System Path env var), текущий каталог |
|
под system path понимается это: 3.The system directory. The name of this directory is System32. 4.The 16-bit system directory. The name of this directory is System. 5.The Windows directory. под user path понимается содержимое переменной PATH, склеенное из системной переменной и переменной для текущего пользователя. Иными словами, %path% (независимо от того, где он задан) всегда идёт последним, текущий каталог может быть или в начале, или в середине. |
|
Тогда "системные каталоги, текущий каталог, %path%" крайне мало отличается от того, что сейчас. Сделать "системные каталоги, %path%, текущий каталог" проблематично? |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-11-09 13:40 | heilong | New Issue | |
2016-11-09 19:13 | DrKnS | Note Added: 0014978 | |
2016-11-09 19:34 | heilong | Note Added: 0014982 | |
2016-11-11 10:23 | JohnDoe | Note Added: 0014987 | |
2016-11-11 11:28 | heilong | Note Added: 0014988 | |
2016-11-11 11:45 | heilong | Note Edited: 0014988 | |
2016-11-11 13:40 | DrKnS | Note Added: 0014990 | |
2016-11-11 13:56 | heilong | Note Added: 0014991 | |
2016-11-11 13:58 | heilong | Note Edited: 0014991 | |
2016-11-11 14:10 | DrKnS | Note Added: 0014992 | |
2016-11-11 14:34 | heilong | Note Added: 0014993 | |
2016-11-11 14:50 | DrKnS | Note Added: 0014994 | |
2016-11-11 15:30 | DrKnS | Note Added: 0014995 | |
2016-11-11 16:50 | heilong | Note Added: 0014997 | |
2016-11-11 17:01 | DrKnS | Note Added: 0014998 | |
2016-11-11 19:27 | heilong | Note Added: 0015001 |