Андрей Дугин: сильно с вами согласен и, если обратите внимание, про import this также писал. Но все же функциональное программирование не путаю с обфускацией. У вас даже переменная называется "buffer", что говорит о том, что вы явно храните состояние, изменяете его - это императивный подход. Мой нехороший пример в топике более функционален, а вот в ветке комментов выше был именно функциональный подход. Поставьте перед собой задачу написать функцию, получающую на вход список, и отдающую список, без сохранения состояния по пути.
Первые 2 варианта "недостаточно интересны", вторые 2, строго говоря, не однострочники, а все тот же императивный алгоритм. Кроме того, что сделает lstrip с доменом 'www.ru'? В общем, вы просто переписали классически, что, конечно же, в реальном коде удобнее. Но суть вопроса была в использовании функционального (!) однострочного стиле.
@WbdT: вспомнил про AppArmor еще! Он проще, чем selinux. С ним можно просто сделать такую штуку, как jailbash - описано, например, тут: askubuntu.com/questions/144211/restricting-ssh-use... Только все равно придется создавать профайл с нужными правами, хотя это и проще сделать значительно, чем в SELinux. Все дело в том, что совсем ограничить пользователя в одну директорию нельзя.
Вывод из всего этого: я бы лучше использовал LXC на всем сервере, значительно проще в обслуживании, идеально подходит для подобного разделения ресурсов. Поднять его несложно, в убунте никогда этого не делал, но делал на centos и arch, в обоих случаях потратил полчаса. И отдайте пользователю LXC без прав рута внутри. SELinux/AppArmor - это, скорее, мощные инструменты для ограничения безопасности всей системы (например, для улучшения изоляции тех же LXC-контейнеров). Но если не хочется LXC, то лучше AppArmor, т.к. SELinux - это сложный в настройке оверкилл.
@WbdT: множество опечаток выше, комментарий удалить/изменить не получается (какие-то работы на тостере, видимо). С SELinux я поверхностно знаком, поэтому конкретные решения не могу привести. А самом начале "Можно использовать chroot".
@WbdT: осторожнее, не нужно пытаться убирать право на чтение ранее созданных файлов, можете все сломать.
Можно использовать. Если кто-либо подключается к серверу по ssh, погуглите в сторону "ssh ChrootDirectory". Если оно есть в конфиге, то пользователь будет ограничен этим каталогом. Никогда нельзя давать такому пользователю root, плюс есть нюансы с chroot. Он не дырявый, но при определенных обстоятельствах можно сделать плохое. Интересное об этом, что вспомнил, https://securityblog.redhat.com/2013/03/27/is-chro... или habrahabr.ru/post/141012 Так что в качестве полумеры вариант неплох, но если реально важна безопасность, то не вариант никогда.
Эту задачу можно точно сделать с помощью SELinux, безопасно и круто. Все сведется к созданию определенных доменов с определенными правами. Я знаком с SELinux, поэтому конкретных решений быстро не приведу, однако они быстро нагуглятся. Пожалуй, это решение в конкретной ситуации вашей.
P.S. Я обычно использую LXC-контейнеры под сайты, БД, если все крутится на одном сервере. В итоге мы имеем песочницу под каждую задачу. Поэтому, как вариант, вы можете создать LXC-контейнер для вашего пользователя, настроить там права, прокинуть нужные ресурсы (и ssh). В итоге он получит значительно больше возможностей, чуть ли не свою ОС. При адекватных настройках, это безопасно. Ресурсов много не ест.
@yttrium: вы выше писали, что печально, что в 3 питоне нет "паттерн матчинга" в параметрах функции. Мне это запомнилось, думал, вы об этом. Вот этот PEP: dinsdale.python.org/dev/peps/pep-3113
@yttrium: Вы запутались в своих неточных выражениях. Изначально написали, что "re быстрее - это обман, потому что в map, который генератор отдает", на что я ответил, что "вообще весь map - обман", на что вы мне ответили, что с "re никакого обмана нет, и что весь map - обман". О чем я говорил, собственно.
В ваш вывод модно добавить, что reduce лучше не скармливать генератор, если список небольшой. Тогда он будет быстрее раза в 2-3, а оптимальность по памяти в таком случае не нужна. Тем более, что большой список - понятие растяжимое. Один кортеж такой в списке занимает около 8 байт (с 1 записью в set), можно посчитать, что будет критично в конкретном случае.
В принципе можно сделать генератор без map со всеми этими for, он почти не проигрывает в скорости. А что касается предварительной декомпозиции кортежа, то я согласен с PEP, оно действительно имеет больше минусов, чем плюсов.
@yttrium: да, со split кривой вариант, просмотрел. Только и replace тоже не панацея: пропустит домены типа www.ru, хотя это уже менее критично, но все же.
Хитпарад интересный. И тут обман не только с re, а вообще с map: если не нужен генератор, то map будет значительно медленнее.
@zedxxx: для упрощения можно принять, что код тот же, но читаемость лучше, т.к. разбит на строки. Но, я так понял, одна строка вас смущает, но несколько строк того же кода + коммент - это уже нормально? :)
@vvpoloskin: без данного правила не будет работать, так как после цепочки (а не правила) PREROUTING пакет идет в цепочку INPUT (в нашем случае, так как пакет не транзитный), и как раз там он дропнется по политике по умолчанию. REDIRECT работает на L4, подменяя dport. После него правило уже не продолжает двигаться по таблице nat, а идет далее. В сути, это разновидность DNAT. Причем, кстати говоря, в таблицу nat попадает только первый пакет соединения, далее они будут проходить мимо данной таблицы.
Да, ваш вариант значительно лучше. Буду использовать вместо того, что выше. Также открыл для себя defaultdict, как же не хватало его, спасибо :)
Только одно не понял: валидация url не нужна, зачем использовать регексп и еще и внутри map, когда можно проще: [(i[0].split('www.')[-1], i[1]) for i in l]
@386DX Кстати говоря, в свое время (чуть более года назад) не встретил ни одной вменяемой статьи насчет того, как это реализовано. Из хорошего есть только про выгрузку из реестра от netangels вроде. Но о примерах внутри провайдеров, полноценного опенсорса для работы с реестром, тонкости/фейлы в реестре (коих там много), как можно законно и правильно его обойти, а также почему не катят линуксовые возможности для организации именно DPI (а не прокси) ничего или почти ничего. На других ресурсах есть частные примеры, отрывки инфы, на хабре в основном политический уклон. Сейчас ситуация на хабре не изменилась. У меня уже есть в черновиках статья, плюс наработки, никак не могу закончить..)
Ну да ладно, вопрос был не об этом, так что не стоит тут флудить.
@386DX Я имею в виду другое. Блокировку не на уровне L3, а на уровне L7 по заголовку в пакете http (Host). Это делает squid tproxy для ip-адресов из списка запрещенных сайтов, которые через эту проксю проходят после анонса по bgp.
Если так не делать, то блокировка легко обходится для многих сайтов, если так делать для всех, то есть проблемы вроде этой с гуглом.
Сейчас сделаю исключения насчет этого. Кстати говоря, собираюсь статью на хабр написать касательно реестра вообще, но не уверен, что ее хорошо примут. Для меня это все ради интереса, а не репрессивного сапога ради. Вообще обо всем: и о реестре, и о том, как это сделано, и о скриптах, которые все это делают (а там уже не просто портянка, а нечто похожее на нормальное ПО).
Спасибо. Немного погуглив в эту сторону, нашел упоминания об этом в файле WifiWatchdogStateMachine.java в исходниках, но не во всех версиях. Видимо, позже этот алгоритм был впилен в другие места, но не суть важно. Это называется как-то вроде "walled garden check".
"On DNS success, the WatchdogService initiates a walled garden check via an http get. A browser window is activated if a walled garden is detected."
Судя по той теме на stackoverflow, этот запрос много где используется. И однажды можно словить переход на страницу, что "данный ресурс заблокирован" (в случае с блокировкой от провайдера).
Что, собственно, я только что протестил. В уведомлениях появляется пункт, что требуется авторизация, после захода в браузер. Нажатие на него перекидывает туда, куда ведет редирект с этого адреса.
В принципе сделано логично все это, но блокировать IP гугла нельзя.
Всем огромное спасибо. Такая проверка, получается, где угодно может быть использована, в любом приложении.
