ls nonse что означает
Пришло СМС от Фейсбука с кодом подтверждения Инстаграм: что это?
25.06.2020 7,095 Просмотры
В сети стало появляться все больше вопросов и жалоб от пользователей относительно кодов подтверждения. На этот раз предметом острых споров и недоумения выступило SMS от Facebook, содержащее код подтверждения для Инстаграм.
Что это может быть
Что же делать
Самое элементарное, что можно сделать в таком случае – это изменить пароль. Данная мера должна быть предпринята в первую очередь. И уже, исходя из дальнейшего развития ситуации, будет решаться вопрос о принятии дальнейших решений.
Если пароль был изменен, а SMS-атака все равно продолжается, то следует сообщить о происходящем в службу поддержки. Для этого требуется открыть меню (клавиша с тремя полосками в правом верхнем углу), выбрать пункт «Справка», в появившемся списке выбрать «Сообщить о проблеме». Далее следует описать суть своей проблемы и желательно приложить скриншот.
Так как у компании нет филиалов в России, горячая линия тоже отсутствует. Поэтому решение возникающих вопросов осуществляется через форму поддержки в мобильном приложении или в браузерной версии, а также через электронную почту. Откладывать и затягивать с обращением не стоит, иначе есть риск потерять аккаунт.
Основы Linux от основателя Gentoo. Часть 3 (2/4): Модель прав доступа
Навигация по основам Linux от основателя Gentoo:
Часть I:
Часть II:
Часть III
Модель прав доступа в Linux
Один пользователь, одна группа
‘d’ директория
‘l’ символическая ссылка
‘c’ устройство символьного ввода-вывода
‘b’ устройство блочного ввода-вывода
‘p’ FIFO
‘s’ сокет
Три тройки
«rwx»
«r-x»
«r-x»
Выше r означает, что чтение (просмотр данных содержащихся в файле) разрешено, w означает запись ( изменение, а также удаление данных) разрешено и x означает исполнение (запуск программы разрешен). Собрав все воедино мы видим, что кому угодно разрешено читать содержимое и исполнять этот файл, но только владельцу (root) разрешено как либо модифицировать этот файл. Так что если нормальным пользователям разрешено копировать содержимое этого файла, то только root может изменять или удалять его.
Кто я?
Перед тем, как мы узнаем как изменить владельца или группу которой принадлежит файл, давайте сперва рассмотрим, как узнать вашего текущего пользователя и группу к которой вы принадлежите. Если вы не использовали команду su недавно, ваш текущий пользователь это тот, которым вы вошли в систему. Если вы часто используете su, вы можете не помнить пользователя под которым вы работаете в данный момент. Чтобы узнать под каким пользователем вы работаете, наберите whoami:
В каких группах я состою?
Чтобы увидеть к каким группам вы принадлежите используйте команду groups:
$ groups
drobbins wheel audio
Из этого примера видно, что я состою в группах drobbins, wheel, и audio. Если вы хотите посмотреть, в каких группах состоит другой пользователь, то передайте его имя в качестве аргумента.
$ groups root daemon
root : root bin daemon sys adm disk wheel floppy dialout tape video
daemon : daemon bin adm
Изменение пользователя и группы владельца
Чтобы изменить владельца или группу файла (или другого объекта) используется команды chown или chgrp соответственно. Сначала нужно передать имя группы или владельца, а потом список файлов.
# chown root /etc/passwd
# chgrp wheel /etc/passwd
Вы также можете изменить пользователя и группу одновременно используя команду chown в другой форме:
# chown root:wheel /etc/passwd
Вы не можете использовать команду chown без прав суперпользователя, но chgrp может быть использована всеми, чтобы изменить группу-владельца файла на ту группу, к которой они принадлежат.
Рекурсивное изменение прав
Знакомство с chmod
$ chmod +x scriptfile.sh
В примере выше в качестве метода указано +x. Как можно догадаться, метод +x указывает chmod, что файл необходимо сделать исполняемым для пользователя, группы и для всех остальных. Если мы решим отнять все права на исполнение файла, то сделаем вот так:
Разделение между пользователем, группой и всеми остальными
До сих пор, наши примеры команды chmod влияли на права доступа всех трех наборов прав доступа — пользователя, группы и всех остальных пользователей. Часто бывает удобно изменить только один или два набора за раз. Чтобы сделать это, просто используйте специальный символ для обозначения набора прав доступа, который вам необходимо изменить, со знаком + или — перед ним. Используйте u для пользователя, g для группы и o для остальных пользователей.
$ chmod go-w scriptfile.sh
Мы только что удалили право на запись для группы и всех остальных пользователей, но оставили права владельца нетронутыми.
Сброс разрешений
Помимо переключения бит, отвечающих за права доступа, в состояние вкл/выкл, мы можем задать конкретные значения для всех сразу. Используя оператор равенства мы можем указать chmod, что хотим задать только указанные права доступа:
$ chmod =rx scriptfile.sh
Этой командой мы установили все биты чтения и исполнения и сбросили все биты записи. Если вы хотите задать значения конкретной тройки бит, то можете сделать это, указав ее символьное наименование перед оператором равенства:
$ chmod u=rx scriptfile.sh
Числовые режимы
До сих пор, мы использовали то что называется символическим способом указания прав доступа для команды chmod. Однако есть еще один достаточно распространенный способ указания прав: использование четырехзначных восьмеричных чисел. Этот синтаксис, называется числовым синтаксисом прав доступа, где каждая цифра представляет тройку разрешений. Например, в 1777, 777 устанавливают флаги о которых мы говорим в этом разделе, для владельца, группы, и остальных пользователей. 1 используется для указания специального бита прав доступа, который мы рассмотрим позже (смотрите «Неуловимая первая цифра» в конце раздела). Эта таблица показывает как транслируются права доступа на числовые значения.
Числовой синтаксис прав доступа
Числовой синтаксис прав доступа особенно полезен когда требуется указать все разрешения для файла, как показано в следующем примере:
umask
Когда процесс создает новый файл, он указывает, какие права доступа нужно задать для данного файла. Зачастую запрашиваются права 0666 (чтение и запись всеми), что дает больше разрешений, чем необходимо в большинстве случаев. К счастью, каждый раз, когда в Linux создается новый файл, система обращается к параметру, называемому umask. Система использует значение umask чтобы понизить изначально задаваемые разрешения на что-то более разумное и безопасное. Вы можете просмотреть текущие настройки umask набрав umask в командной строке:
В Linux-системах значением по умолчанию для umask является 0022, что позволяет другим читать ваши новые файлы (если они могут до них добраться), но не изменять их. Чтобы автоматически обеспечивать больший уровень защищенности для создаваемых файлов, можно изменить настройки umask:
Такое значение umask приведет к тому, что группа и прочие не будут иметь совершенно никаких прав доступа для всех, вновь созданных файлов. Итак, как работает umask? В отличие от «обычного» назначения прав доступа к файлу, umask задает какие права доступа должны быть отключены. Снова посмотрим на таблицу соответствия значений чисел и методов:
Знакомство с suid и sgid
В момент вашего входа в систему запускается новый процесс оболочки. Вы уже знаете об этом, но можете не знать о том, что этот новый процесс оболочки (обычно это bash) работает от имени вашего пользователя. И таким образом программа bash может обращаться ко всем файлам и директориям, владельцем которых вы являетесь. В действительности мы, как пользователи, полностью зависим от программ, выполняющих операции от нашего имени. И поскольку программы, которые вы запускаете, наследуют ваш пользовательский идентификатор, они не могут обращаться объектам файловой системы, к которым вам не предоставлен доступ. К примеру, обычные пользователи не могут напрямую изменять содержимое файла passwd потому что флаг записи отключен для всех пользователей кроме root:
Однако, обычным пользователям тоже нужно иметь возможность хотя бы опосредованно менять содержимое /etc/passwd когда им понадобится сменить пароль. Но если пользователь не может изменить этот файл, как это сделать?
К счастью, в модели прав доступа Linux имеются два специальных бита, называемых suid и sgid. Когда для запускаемой программы установлен бит suid, она будет работать от имени владельца исполняемого файла, а не от имени того, кто запустил программу. Теперь можем вернуться к вопросу с /etc/passwd. Если посмотрим на исполняемый файл passwd, увидим, что его владельцем является пользователь root:
Обратите внимание, что вместо x в триплете прав доступа владельца стоит s. Это означает что для этой конкретной программы установлены биты suid и права на запуск. По этой причине при запуске программы passwd она будет работать от имени пользователя root (со всеми правами доступа суперпользователя), а не пользователя, запустившего её. И поскольку passwd работает с правами суперпользователя, она способна редактировать /etc/passwd без каких либо сложностей.
Предупреждения о suid/sgid
Изменение suid и sgid
Способ установки и удаления битов suid и sgid чрезвычайно прост. Вот так мы задаем бит suid:
# chmod u+s /usr/bin/myapp
А в следующем примере мы снимаем флаг sgid с директории. Вы увидите, как бит sgid работает с директориями немного ниже:
# chmod g-s /home/drobbins
Права и директории
До текущего момента мы рассматривали права доступа с точки зрения обычных файлов. Когда речь заходит о директориях, появляются некоторые отличия. Директории используют те же флаги прав доступа, но их интерпретация имеет немного другой смысл.
Если для директории задан флаг чтения, то вы можете просматривать список содержимого директории; флаг записи означает, что вы можете создавать файлы в директории; и флаг исполнения означает, что вы можете войти в директорию и обращаться ко всем поддиректориям внутри. Без флага исполнения у вас не будет доступа к объектам файловой системы внутри директории. Без флага чтения объекты файловой системы внутри директории нельзя просмотреть, но к объектам внутри директории все еще можно обратиться, если вы знаете полный путь к объекту на диске.
Директории и флаг sgid
В случае же, если для директории установлен бит sgid, все объекты файловой системы, создаваемые внутри, наследуют группу директории. Эта возможность бывает кстати, когда вам необходимо создать дерево директорий и все они должны принадлежать одной группе. Это можно сделать вот так:
# mkdir /home/groupspace
# chgrp mygroup /home/groupspace
# chmod g+s /home/groupspace
Теперь любые пользователи группы mygroup могут создавать файлы и директории внутри /home/groupspace и им также будет автоматически задана принадлежность группе mygroup. В зависимости от настроек umask для данного пользователя новые объекты файловой системы могут быть или не быть читаемыми, изменяемыми или исполняемыми другими пользователями группы mygroup.
Директории и удаление
По умолчанию директории в Linux ведут себя не самым удобным во многих ситуациях образом. Обычно кто угодно может переименовать или удалить файл внутри директории если у них есть права на запись в этой директории. Для директорий, которыми владеют отдельные пользователи, такое поведение обычно не вызывает проблем.
Хорошая новость в том, что в Linux существует так называемый sticky бит. Когда для /tmp установлен sticky бит (командой chmod +t), единственные, кто могут удалить или переименовать файлы в /tmp — это либо владельцы этих файлов либо суперпользователь.
Неуловимый первый знак
В завершение этого раздела мы наконец обратим внимание на первый знак, используемый в численном синтаксисе. Он используется для задания битов sticky, suid и sgid:
Ниже приведен пример того, как использовать 4-значный режим для установки прав доступа на директорию, которая будет использоваться рабочей группой:
# chmod 1775 /home/groupfiles
В качестве домашней работы выясните что значит 1755 в настройках прав доступа. 🙂
Перевод выполнил коллективный разум с помощью notabenoid.com. Спасибо следующим benoid-юзерам (в алфавитном порядке): kindacute, nekjine, Rich. Отдельная благодарность Алексею Блажко (blazhkoa@gmail.com), а также инициатору всей серии переводов, VBart.
Об авторах
Daniel Robbins 
Дэниэль Роббинс — основатель сообщества Gentoo и создатель операционной системы Gentoo Linux. Дэниэль проживает в Нью-Мехико со свой женой Мэри и двумя энергичными дочерьми. Он также основатель и глава Funtoo, написал множество технических статей для IBM developerWorks, Intel Developer Services и C/C++ Users Journal.
Chris Houser
Крис Хаусер был сторонником UNIX c 1994 года, когда присоединился к команде администраторов университета Тэйлора (Индиана, США), где получил степень бакалавра в компьютерных науках и математике. После он работал во множестве областей, включая веб-приложения, редактирование видео, драйвера для UNIX и криптографическую защиту. В настоящий момент работает в Sentry Data Systems. Крис также сделал вклад во множество свободных проектов, таких как Gentoo Linux и Clojure, стал соавтором книги The Joy of Clojure.
Угнать за 1100 секунд – самый странный баг, который я видел
Два дня назад я получил странное сообщение от клиента: видеозвонок загадочно оборвался ровно через 18 минут. А потом это случилось снова, также после 18-ой минуты. Совпадение?
Этот баг был не только странный, но и страшно неловкий. Наша цель – делать настолько простой инструмент для видеозвонков, чтобы условный доктор или психолог захотел бы пользоваться нашим сервисом. Надо ли говорить, что постоянный разрыв через 18 минут не согласуется с такой целью?
WebRTC – это когда вы всегда имеете дело с багами
Баги – это не какой-то феномен для нас. Наш продукт основан на WebRTC, довольно новом веб-стандарте, который позволяет двум браузерам напрямую обмениваться данными (например, видео и аудио в реальном времени).
В сентябре 2017, WebRTC наконец стал поддерживаться во всех основных браузерах. За последние месяцы мы урвали свою честную долю багов, пока заставляли WebRTC работать для всех. (Работа с передовыми технологиями – это хороший способ познакомиться с тем, как писать баг-репорты производителям браузеров).
Однако этот последний баг был самым странным за мои 5 лет работы с WebRTC.
Инструменты для отлова багов WebRTC
К счастью, у нас есть много инструментов для отлова багов (спасибо некоторым крутым контрибьюторам). Наивно думать, что некто сделает дамп chrome://webrtc-internals и пришлет его вам вместе со сценарием, который легко воспроизвести.
Пример вывода на основе дампа WebRTC. Зеленые линии обозначают успешное соединение, красная линия – сбой соединения.
Один из лучших инструментов – это rtcstats, который дает вывод из getStats и хранит его в обычных файлах (наряду с другим полезными фишками).
Подтверждение бага
Мы быстро нашли искомые файлы из двух сбойных звонков. Это были видеозвонки между Chrome 64 и Edge 16. Chrome упал на 18 минуте 20 секунде. Последующий рестарт ICE тоже не удался, что автоматически закрыло RTCPeerConnection.
Загадка в том, что Edge не согласился с Chrome – на стороне Edge iceConnectionState оставался подключенным вплоть до рестарта ICE, браузер разорвал соединение только провалился рестарт ICE. Что это было?
Скрин из Edge, посмотрите на временные метки connected и получения описания iceRestart, между ними примерно 18 минут 20 секунд. Причем iceConnectionStateChange даже не изменился на failed!
Воспроизвести баг: магическое число “18 минут 20 секунд”
Пару месяцев до этого мы купили дешевый ноутбук с Windows, чтобы запускать Edge 16 и видеть баги в действии. Мы делали видеозвонок между этим ноутбуком и Макбуком с Chrome 64.
А потом мы ждали. И разумеется, ровно после 18 минут 20 секунд статус ICE меняется на failed, рестарт ICE не удается и соединение рвется. Мы никогда не видели ничего подобного, это был шок.
Что же делать дальше? С чего начать? В нашем коде не было магического таймера, который бы рвал соединения после 18 минут 20 секунд в некоторых браузерах. Все это казалось непреодолимым, но мы могли сделать только одно.
Команда в блаженном неведении о багах, которые ее ожидают. Фото сделано в Олесунне, Норвегия, во время рабочей поездки.
Один шаг за раз – методичная локализация бага
Мы нашли воспроизводимый сценарий, но все еще надо было уменьшить область поиска. Серия тестов должна была проверить наши предположения.
Во-первых, случится ли подобное между двумя браузерами Chrome, в которых обычно меньше всего проблем с WebRTC? На тех же ноутбуках, с теми же начальными условиями мы проверили звонок из Chrome в Chrome. Через 18 минут 20 секунд звонок все еще был активен, состояние соединения ICE оставалось стабильным. То есть баг не случился.
Тем не менее, при тесте из Firefox в Edge, звонок опять сорвался.
Главный вопрос: это баг в Edge или баг в нашем коде? Сервис appear.in тоже построен на WebRTC и в нашем продукте многое сделано так же, потому что половина нашей команды раньше работала в appear.in. Мы решили протестировать звонок из Chrome в Edge через эту платформу в режиме peer-to-peer (бесплатно), все на тех же машинах. Ни единого разрыва!
Мы не знали, плакать или смеяться. Область поиска сузилась и указывала на ошибку в нашем коде. Confrere не мог работать для связки Chrome-Edge.
Когда ожидания рушатся
Так как каждый тест занимал 20 минут, мы решили, что надо приостановиться и продолжить уже из дома.
Ради лишней проверки, мы протестировали Chrome-Edge из дома. Каково же было удивление, когда после 40 минут теста звонок все еще был активен. Что?!
Мы проверяли всё снова и снова. Chrome логировал, что соединение в офисе делало так: relay stun. Это значит, что одно плечо звонка должно идти через наши сервера (relayed), а вот второе плечо может отправлять данные напрямую (STUN). Это не редкость для современных сетевых конфигураций.
Дамп RTCStats показывает статус соединения каждый пары ICE-кандидатов. Посмотрите на самый верх: локальный адрес в статусе relay, а удаленный – в статусе stun.
Из-за специфической конфигурации сети в нашем офисе, моя машина, запускающая Chrome, была подключена через кабель, чтобы позволить прямые соединения. Ноутбук с Edge цеплялся по очень нестабильному Wi-Fi, и использовал relay-сервер. Однако в домашней сети, стороны звонка соединялись через локальных кандидатов, то есть не покидали домашнюю сеть.
IceTransportPolicy спешит на помощь!
Следующий шаг – определить, почему в офисе тест был неудачным, но теперь вдруг заработал. Могла ли причина быть в stun- или relay-кандидатах? К счастью, мы можем заставить PeerConnection использовать только relay-кандидатов – надо проставить соответствующее значение у iceTransportPolicy, когда создается PeerConnection. И разумеется, через 18 минут 20 секунд звонок обрывается.
Были ли это совпадение, что связка Chrome-Edge работала в appear.in? Может быть, наше соединение через appear.in использовало STUN, но в нашем сервисе победил TURN? Быстрый тест показал, что дело в нашей ошибке, так как принудительный relay (TURN) для appear.in не вызвал багов.
Наконец, мы попробовали еще кое-что. Мы собрали особую версию Confrere и с разрешения appear.in использовали их TURN-серверы для одного теста. Спустя 25 минут мы сделали вывод, что код в нашем клиентском приложении был в порядке (потому что этот код не провоцировал баг при использовании других TURN-серверов).
Когда каждый тест занимает минимум 18 минут, то это требует терпения. Слева я, справа – Свейн (CEO)
Логи спешат на помощь!
Когда мы локализовали проблему – виновата наша конфигурация TURN-серверов – мы могли все починить? Нет. Мы до сих пор не знали, что именно вызывало этот баг. Наша TURN-инфраструктура по большей части основана на том, что мы узнали за 4 года работы в appear.in, она использует те же опенсорсные компоненты, работает в том же облаке и с той же конфигурацией.
Когда вы в полной растерянности и не знаете, куда двигаться дальше, вы всегда можете обратиться к логам. Логирование было для нас главным инструментом в поиске бага, потому что оно позволяет в реальном времени следить за работающей системой. Запустив новый видеозвонок, мы пристально следили за логами.
Где-то на 10-минутной отметке стали учащаться сообщения вида:
Когда звонок оборвался через 18 минут 20 секунд, мы снова просмотрели логи и нашли первое сообщение с упоминанием Stale nonce:
Почему так много сообщений про Stale nonce? Что это вообще за одноразовый код (nonce) и как он может быть просроченным (stale)?
Понять баг: Привет, «stale nonce»
Если вы, так же как и я, раньше не знали, что такое одноразовый код (nonce):
Nonce (от англ. nonce — «number that can only be used once» — число, которое может быть использовано один раз) в криптографии — одноразовый код, выбранный случайным или псевдослучайным образом, который используется для безопасной передачи основного пароля, предотвращая атаку повторного воспроизведения.
И если это число просрочено:
Stale nonce это больше предупреждение, чем ошибка. Для SIP ваши авторизационные данные зашифрованы в SIP-заголовках. Чтобы эти данные не могли перехватить другие люди и делать звонки за ваш счет, используется одноразовый код (nonce).
Стандарт SIP RFC требует, чтобы nonce периодически менялся. Если клиент использует старый nonce, то это “stale nonce”. В этом случае клиент обязан использовать текущий nonce вместо старого. Такое сообщение означает, что клиент пытается использовать stale nonce, то есть либо происходит атака повторного воспроизведения, либо клиент не смог получить новый nonce
В Confrere используется опенсорсное ПО coturn, оно управляет TURN-серверами. Если вы внимательно прочтете документацию, то увидите, что в конфигурации есть параметр для stale nonce:
В своей конфигурации мы включили stale-nonce и все безупречно работало, пока база клиентов с браузером Edge не начала расти.
Логи stale nonce были знакомы Филиппу Ханке, он же и помог нам понять, что к чему. Шиджун Сун сообщал в appear.in о похожей проблеме в мае 2017-го, что позволило appear.in избежать проблем.
У нас была возможность изменить конфигурацию TURN-сервера и убрать флаг stale-nonce, чтобы nonce не имел ограничений по времени.
50 минут в тестовом окружении – и мы наконец смогли сказать: «Мы нашли баг!»
И все-таки, почему 18 минут 20 секунд?
Должно быть, вы заметили заголовок этого поста. Угнать за 1100 секунд. В этом тексте я писал “18 минут 20 секунд”, а знаете, сколько это в секундах? 1100.
Мы знаем, что через 600 секунд от начала разговора начальный nonce становится невалидным. Возникает сообщение stale nonce и еще через 500 секунд соединение рвется. Откуда берутся еще 500 секунд?
Если в сорцах coturn поискать число 500, то найдется кое-что интересное.
Выглядит как встроенный таймер сна через 500 секунд после какой-то проверки соединения. Я не слишком знаком с внутренним устройством coturn, но судя по всему, если nonce становится невалидным, то через 500 секунд после этого coturn прекратит передачу пакетов другому участнику. Конечно же, другой участник при этом увидит, что соединение разорвано (ведь он больше не получает пакеты).
Это объясняет происходящее со стороны Chrome, так как ему перестают приходить пакеты. Но почему Edge не замечает этого?
История о двух пакетах
Соединения в WebRTC могут быть двух видов: UDP и TCP. Для пакетов UDP не требуется подтверждение о получении, не гарантируется доставка и они могут приходить не в том порядке. В коммуникациях реального времени это не большая проблема, так как кодеки довольно хорошо справляются с потерей пакетов.
У TCP все по-другому. TCP очень полезен, когда нужно доставить все данные другой стороне, в правильном порядке и с подтверждением доставки. Большая часть трафика WebRTC – это UDP.
В нашей истории Edge отправлял UDP-пакеты через TURN-сервер другой стороне. Когда сервер WebRTC прекращал передавать пакеты, Edge никак не мог знать, получал ли Chrome пакеты или нет, поэтому Edge продолжал радостно слать данные. С другой стороны, Chrome вел себя правильно и отправлял пакеты через STUN. Так что когда происходил iceRestart, Edge не знал, что делать и просто по-тихому падал.
Итоги
Выводы такие: мы отправим баг-репорт в баг-трекер Edge и на некоторое время развернем новые TURN-сервера без флага stale-nonce. Новые серверы должны гарантировать, что в будущем не будет сбоев, и наши пользователи получат долгие и качественные видеозвонки в нашем сервисе.
Также я невероятно рад быть частью сообщества людей, которые охотно делятся знаниями и помогают друг другу. От разработчиков браузеров, которые отвечали на наши баг-репорты и фиксили баги, до отдельных контрибьюторов, которые делают превосходный и бесплатный инструментарий для сообщества WebRTC.
Отдельное спасибо Филиппу Ханке за то, что указал нам на флаг stale-nonce и терпел мои бесконечные причитания, когда все это казалось бессмыслицей. Кроме того, выражаю признательность Шиджун Суну за то, что открыл эту проблему в мае 2017-го.
Надеемся, эта история была полезна для вас. С автором оригинальной статьи можно связаться через Твиттер или почту, а я готов поделиться нашим опытом использования WebRTC в комментах!