Общая форма для scp при локальном копировании на удаленный:
scp localfile username@remotehost:/some/remote/directory
В этом случае вы сообщаете scp, что хотите войти в систему как username на удаленной системе, и это имя пользователя, с которым будет происходить запись. Скорее всего, в вашем примере вы использовали userB, когда просматривали файл на компьютере B.
Если вы копировали удаленный файл на локальный хост, например:
scp username@remotehost:/some/remote/file /some/local/directory
В этом случае вы входите в систему как username в удаленную систему, а затем записываете его локально как пользователь, под которым вы запускаете команду scp. В этом примере будет скопирован файл с удаленного хоста в систему, в которой вы работаете, в качестве пользователя, в котором вы в данный момент вошли (поскольку запись будет выполняться пользователем, вошедшим в данный момент). Это не повлияет на что-либо на удаленном хосте, так как вы только читаете файл оттуда и копируете его на локальный хост. Поскольку вы можете читать удаленный файл, локальный файл должен иметь для вас права на запись, так как вы пишете файл локально.
Другими словами, владелец файла обычно совпадает с автором файла. Итак, если вы вошли в систему как пользователь А и написали файл, владельцем будет пользователь А. Более простой пример может быть примерно таким:
user@server:~$ ls -l /var/log/syslog
-rw-r----- 1 syslog adm 6615 Apr 9 17:09 /var/log/syslog
Обратите внимание, что этот файл принадлежит системному журналу, но он доступен для чтения любому пользователю группы adm, к которому принадлежит пользователь. Затем, если мы скопируем файл в домашний каталог пользователя (~/):
user@server:~$ cp /var/log/syslog ~/
user@server:~$ ls -l ./syslog
-rw-r----- 1 user user 6615 Apr 9 17:10 ./syslog
Обратите внимание, что скопированная версия файла теперь принадлежит user . scp делает то же самое, за исключением того, что источник или назначение могут включать в себя вход другого пользователя в другую систему.
Обратите внимание, что разрешения отслеживаются с помощью идентификатора пользователя, числового представления пользователя. Вы можете увидеть свой текущий UID с помощью команды id . Как правило, для отдельных систем идентификаторы UID не должны совпадать с системой, поскольку учетные записи не являются общими (если вы не используете LDAP или аналогичный). Я считаю, что традиционно 0 - это root, UID менее 1000 зарезервированы для системных учетных записей (например, почты, новостей, bin, daemon и т.д.), И что обычные пользователи начинают с 1000. Насколько мне известно, обычные пользовательские идентификаторы назначаются последовательно, поэтому, если вы создали три учетные записи, они, вероятно, будут 1000, 1001 и 1002.
Возвращаясь к исходному вопросу о том, как отправить файл только для чтения, вы должны убедиться, что читатель в удаленной системе не имеет того же UID, что и владелец файла. т.е. если вы (userA) готовили файл для userB, вы могли бы сделать что-то вроде:
scp localfile userA@remotehost:/some/remote/directory
В этом случае владельцем файла будет пользователь A (и мы знаем, что пользователь userA существует в удаленной системе, так как именно в него мы вошли), и пользователь B не будет иметь прав на запись (при условии, что файл изначально был 755). ). Изменить: вам может понадобиться -p, чтобы сохранить разрешения?
Конечно, если пользователь B имеет права root или sudo, он сможет сделать файл доступным для записи независимо от того, что вы делаете.
