Хранитель паролей KeePassX


На просторах интернет обнаружил свободную программу с открытыми исходными текстами KeePassX[link1]. Это хранитель паролей для систем на базе Linux. Возможно окажется полезной в повседневной работе. Возможно кто-либо из участников форума может дать какие-либо комментарии по поводу этой программы, если уже приходилось с ней сталкиваться.
Программа имеет русский и интуитивно понятный интерфейс, а так же довольно приятна в работе.



Комментарии
— SATtva (23/12/2009 19:45)   
Писали как аналог PasswordSafe для KDE. С точки зрения пользователя, программа нормальная. Но использую её большей частью просто как записную книжку, так что в безопасность особенно не вдавался.
— Genosse (24/12/2009 03:13)   
Да нет же, это версия Keepass[link2] для Linux. База паролей, созданная мной с помощью Keepass 1.хх под Windows, была корректно ею "смонтирована".
— Kent (03/01/2010 01:19)   
Использую эту программу. К KDE она отношения не имеет, использует библиотеки Qt4.
Виндовый KeePass открывает базу паролей KeePassX.
— neverever (08/05/2013 20:11)   
прошу прощения за некропостинг, озаботился проблемой межплатформенного хранения паролей. По всем параметрам понравилась эта програма. Смущает то, что за все годы она как-то медленно развиваеться и реже чем прототип обновляется. Есть ли какая-либо положительная или отрицательная статистика по данному продукту?
Гость (10/05/2013 13:17)   
В последнее время они активно готовят релиз 2, на днях вышла уже 4 альфа. Видимо это связано с тем, что старший брат KeePass начиная с версии 2 стал кроссплатформенным.
Гость (12/05/2013 04:29)   
А как вообще правильно хранить пароли? Если профиль узявим, всё равно украдут их все. Можно менять права на доступ к файлу перед получением пароля из него, а затем снова восстанавливать их обратно, но это всё равно не даёт 100%ой защиты. Нужен какой-то интерфейс доступа к паролям, работающий по сетевым запросам, да ещё такой, чтобы авторизация на выдачу была из-под другого пользователя (из других иксов, другой текстовой консоли).

Как работают хранители паролей? Чем обеспечивается безопасность при взломе профиля? Что мешает злонамеренному коду перехватить пароль на открытие базы хранителя паролей?
— SATtva (12/05/2013 13:43)   
Как работают хранители паролей?

Работают так, что система пользователя считается безопасной. Если у Вас там рассадник троянов, то поможет разве что отдельный ноутбук без подключения к сети.
— Вий (12/05/2013 13:57)   
Если профиль узявим, всё равно украдут их все. Можно менять права на доступ к файлу перед получением пароля из него, а затем снова восстанавливать их обратно, но это всё равно не даёт 100%ой защиты.

Видимо поэтому я и не использую KeePassX, поскольку вводя пароль к базе я одномоментно открываю хранилище на все пароли, хотя программа сама по себе мне нравится. У меня каждый пароль хранится в своем персональном текстовом файле, каждый файл по отдельности шифрую с использованием gpg. Это конечно все равно не исключает атаки на главный пароль, с помощью которого я провожу шифрование и который у меня только в голове, но из двух зол стараюсь выбирать меньшее.
— neverever (12/05/2013 14:59)   
Что же это за троян такой который как только вы вскрыли базу утащил отдельными запросами все пароли из нее? Вы под админом сидите? Это эксклюзив писанный под вас? На мой взгляд самый большой риск таких программ если кто-то (либо сами создатели) сделали закладку. Главное что сама база к которой обращается программа по моим запросам лежит на шифрованном диске. Ну и еще меня немного смущают порты на мобильные устройства. Их сорсов я нигде не нашел да и кто их делал мне не понятно.
— neverever (12/05/2013 15:07, исправлен 12/05/2013 15:08)   

Кстати на шифрованный диск положил так как основной пароль могут всетаки украсть самым простым трояном. Ну а остальные только по мере запросов к ним, я ничего не путаю?

— unknown (12/05/2013 17:15)   
Большинство уязвимостей, например браузеров, связаны с чтением произвольного пользователського файла. Реже бывает возможность записи, а запуск произвольного кода — это уже совсем катастрофично, рассчитывать на какую-то защиту от самой программы в этом случае почти бесполезно.

В то же время, часто приходиться пользоваться множеством веб-ресурсов, требующих пароль, логин и какие-то учётные данные. Лучше, чтобы они все были уникальными, в то время как их сохранность не слишком критична — такие пароли все не запомнить, зато можно выбрать компромисс между безопасностью и удобством хранения.
Гость (13/05/2013 00:42)   

Тогда складываем все пароли в текстовый файл и не паримся, получается?


Не обязательно. К примеру, трой строит список всех файлов в директории, а потом сливает их атакующему. Дальше атакующий сам подумает, что из этого надо бы перелить к себе на диск.


Нет, зачем же под админом? Да и нет у меня на ПК такого пользователя. root есть, админа нет. Самый простой пример — трой встраивается в какой-нибудь неуинонный процесс, не привлекающий внимания. Без тщательного аудита системы вы не заметите ничего подозрительного. Этот процесс постоянно висит и в цикле отслеживает момент, когда база с паролями будет доступна на чтение. Как только наступает нужный момент, всё читается и позже сливается в сеть. Методы доставки трояна — через уязвимости в закрытом коде или экспуатация уязвимости браузера: адфыр, ылнзу, ашкуащчю.
— SATtva (13/05/2013 07:45)   
Этот процесс постоянно висит и в цикле отслеживает момент, когда база с паролями будет доступна на чтение.

Файл БД — не криптоконтейнер, открываемый на произвольный доступ. Расшифрование производится в памяти, так что троян должен либо иметь возможность чтения памяти из произвольного процесса, либо логгировать ввод пароля к БД.
Гость (13/05/2013 09:02)   
Тогда складываем все пароли в текстовый файл и не паримся, получается?

От простых троянов и для хранения базы на внешних и сетевых дисках не помешает, не так-ли?

К примеру, трой строит список всех файлов в директории

Стоит хранить базу построже чем бросить просто в домашнюю директорию.
Более сложный троян как вы описали да еще и на системе где под рутом сидят будет означать, что конкретно ваш фаил с паролями комуто очень сдался. Тогда да скорее всего они его получат тем или иным способом.

Методы доставки трояна — через уязвимости в закрытом коде или экспуатация уязвимости браузера: адфыр, ылнзу, ашкуащчю.

если вы что-то делаете в интернете, что может выделить вас из более чем милиарда и сделать интересным залезть на ваш компьютер что бы сперепть фаил ключей который валяеться просто в домашней папке. И при всем при этом если вы делали привлекающие внимания операции в открытую под своим IP да и черес уязвимый браузер с включенным флешем, джавой, одновременно болтая по скайпу, да еще и ник с почтой оставили такиеже как скажем в фейсбуке. Ну чтож... храните тогда пароли лучше в текстовом виде в файле на рабочем столе. Даже проще сделайте везде пароль Qwerty.
Заранее простите за сарказм, но мне кажеться, что первой линией защиты от спирания фаила ключей просто быть неуловимым Джо который yf[hty никому не нужен.
P.S. Как человек я могу жестоко ошибаться, а вы наоборот все верно сказали.
Гость (18/05/2013 17:49)   

Если речь идёт о
запуск произвольного кода,
то что помешает трояну, запущенному с правами текущего пользователя, прочитать память другого процесса, запущенного от имени этого же пользователя? Или всё не так просто?


Не сидят.


Хожу на pgpru.com.


Да, запускал Tor.


Могу объяснить чуть подробней. Пользователь, под которым запускается, например, браузер с флэшом, можно считать заведомо скомпрометированым, поскольку до исполнения произвольного кода тут рукой подать. То же самое касается браузера с джавой или скайпом. То есть, по-хорошему, такие программы должны запускаться под отдельным пользователем и отдельными иксами, что не очень-то удобно. Допустим, зловред типа флэша запускается под основным пользователем, под которым находится, в том числе, и база данных паролей. Что можно легко предпринять для защиты от кражи паролей, если делать быстро и на коленке? Залогиниться в консоли под рутом и убрать права на чтение БД этим пользователем. Защита прекрасная, но только как потом оттуда пароли тягать? Если делать тупо и глупо, то вот так: логинимся под рутом, меняем права, потом под основным пользователем извлекаем пароль или обновляем существующий, после чего снова возвращаем права на исходные. Да, это криво, неудобно, да и защита очень сомнительная. Вот я и хотел спросить у местных гуру, насколько всё запущено и насколько легко эта схема взламывается (подозреваю, что при данных предположениях — элементарно).
Гость (18/05/2013 17:56)   

Уязвимость браузера ≠ уязвимость Flash. Последний — вообще полноценный хозяин в системе. Это независимый процесс, который сам лазит в сеть и делает, что ему вздумается[link3].
— SATtva (21/05/2013 08:57)   
Что можно легко предпринять для защиты от кражи паролей, если делать быстро и на коленке?

Двое иксов, каждые со своим отдельным пользователем, в одних (А) — браузер, в других (Б) — база паролей. Под иксами Б копируем нужные реквизиты в общедоступный файл в /tmp, возвращаемся в иксы А и копируем реквизиты из файла в окно браузера.
— невер (21/05/2013 09:15)   
по мне так это все тоже самое, только еще и с извращениями. Если у вас в системе сидит злой флэш/троян и только и ждет как базу стащить то, что ему мешает стащить все ваши пароли по одному по мере использования? Это тогда просто вопрос времени, а не защита.
— SATtva (21/05/2013 09:26)   
Гражданин, Вы же всё равно вводите пароли через браузер, он их так или иначе получает. Ну, передавайте через астрал, Касперский вроде ещё не сообщал об отсраастральных троянах.
Гость (22/05/2013 19:45)   
так я про это и говорил. Должен же быть предел шизофрении, а то так уже можно и свое второе я подозревать. А то вздруг вы днем на пгп ру сидите, а ночью ваше второе я шлет письма мелким подчерком.
Лично меня, как я и сообщал уже в теме устроит отсутствие закладок в самой програме и стойкость шифра. А все остальное я отношу к организационным проблемам. Мойте руки перед едой, товарищи. Ну и не читайте советских газет.
Гость (22/05/2013 23:31)   
ваше второе я
это не параноя, а раздвоение личности. а не доверять себе – нормальный подход.
Гость (23/05/2013 05:34)   

Передадим IP-пакеты с помощью голубей Сделаем IPC своими руками. :)


Да, замечание совершенно справедливое. Пусть будет «костыль в надежде, что атакующий не сможет грамотно провести атаку», а по-хорошему — да, нет доверия к процессам конкретного пользователя — не может быть доверия и к безопасности паролей, которые из-под него используются.
Гость (28/12/2013 22:58)   

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

  1. Создаём чистый профиль, настраиваем его по-минимуму, скидываем в него файл с паролями, разрешаем доступ к файлу паролей только от рута, и сохраняем весь этот профиль в бэкап.
  2. Когда нужно зайти на чувствительный сайт, удаляем всё старое, что было в профиле (его домашнюю директорию), восстанавливаем чистую копию из бэкапа, логинимся, открываем терминал.
  3. Под рутом в текстовой консоли меняем права на файл с паролями, возвращаемся в графику и делаем cat passdowrds_file | grep <site_name> для извлечения паролей на нужную категорию и только неё.
  4. Возвращаемся обратно в текстовую консоль и (под рутом) возвращаем права на доступ к файлу (теперь его может читать только root).
  5. Идём обратно в графического юзера и запускаем firefox. Логинимся на сайт, пароли копируем из терминала.

Если после этого надо зайти на другой сайт, повторяем всю процедуру (шаги 2-5) заново. При такой схеме есть какие-то гарантии, что пароль, например, на сайт-2 не может быть украден, во время работы браузера с сайтом-1. Есть гарантии, что добавленная уязвимость в профиль всегда нивелируется восстановлением копии из бэкапа (временные файлы с /tmp и /var, если трубется, тоже можно подчищать). Но если не громоздить такую схему, а просто держать файл с паролями под рутом, к которому давать доступ руками, когда надо, то почти вся заявленная безопасность улетучивается.

Кто может, покритикуйте предложенное решение.
Гость (24/05/2014 16:32)   
Кто может, покритикуйте предложенное решение.

Традиционная ахинея из подпорок с распорками из-за безграмотности, так же именуемая в народе: «колхоз». Типична для человека незнакомого с разницей между дискретной и мандатной системой контроля доступа. Потому айда восполнять пробелы, а так же что в этом плане предложило АНБ со своим SELinux и для чего используют «песочницы»(sandbox).

!И не смей агрессировать, реально колхоз жуткий предложил, иди действительно восполняй пробелы в познаниях.
Гость (25/05/2014 00:59)   
Распишите по шагам, как это сделать через SELinux, причём так, чтоб было короче, проще, удобней и надёжней, чем выше предложено. А то тут были жалобы что официальные дистрострители не могут SELinux приркутить, делают как попало, и сами не понимают, как он работает.

[offtop]
в[link6]сё Debian-коммунити, вместе взятое, так и не осилило базовые патчи SELinux под последний релиз.

С[link7] программами и демонами понятно. Для многих из них правил просто нет и они незащищены. Для других правила настолько глючат, что не допиливаются даже вручную. Для третьих вроде оно работает, но насколько это только видимость защиты — понять сложно.

Это может спасти в случае уязвимости в TBB, но в особо хитрых случаях может быть и обойдено.

В[link8] итоге толку от обоих может быть мало — один плохо настраивается и толком не работает, другой добавляет столь мало безопасности, что иногда больше создаёт её иллюзию.

С[link9]удя по количесту багов даже в правилах, поставляемых самими разработчикам SELinux, вполне возможно, что он хорош в теории, а на практике многое в плачевном состоянии.

Н[link10]о вообще, SELinux всё ещё кривой и ужасный. По крайней мере в исполнении Debian. Приходиться использовать только стандартные политики (выучить и понять весь его синтаксис нет сил), выгружать часть глючных модулей (оставляя часть программ без защиты). Те модули, которые относительно успешно можно запустить хотя бы с глюками, есть возможность дополнять своими политиками в соответствии с тем, что выдаёт audit2allow, что есть неправильно и заведомо опасно (но лучше, чем совсем без них). И после каждого обновления есть шанс получить много геммороя с поиском причин глюков и перенастройкой. Стандартную поставку очень хреново обновляют. Иногда приходиться его полностью отключать (превращение защиты в театр). Но хоть какая-то защита (по принципу — в плане защиты SELinux не делает хуже, он может сделать "лучше, чем ничего" или ничего не сделать).

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

В[link11]сё зависит от степени параноидальности настроек. Но по большому счёту, да эти security-панцири не панацея, а не более чем костыль.

С[link12]ложность в создании правил компактного описания разрешений/запретов из-за сложности самого ядра.

В[link13] новых версиях SELinux ещё больше интересных возможностей и утилит ... но вся разработка ведётся на Fedora Linux, а в другие дистрибутивы всё переходит очень медленно.

О[link14]н [SELinux] по умолчанию почти везде отключен и реально крайне мало где используется.

Е[link15]сть sandbox'ы, jail'ы, но всё это либо костыли, либо сводится к ослабленной защите метода «разные приложения — только под разными юзерами».

И[link16]нтереснее подход с псевдовиртуалками (LXC). Сами по себе они не дают безопасности (рут в LXC = рут в системе и выход из псевдовиртуалки). Но для LXC уже сейчас есть специальные правила SELinux, которые исключают такую возможность, делая их допустимо безопасными. Стоит отметить, что проблема анонимности за счёт профилирования железа при этом не решается.

п[link17]ока у файлов есть только "владелец, группа, другие" + довесок ACL или MAC, а у процессов нет ролей и доменов безопасности и т.п., то хоть чрутьте, хоть ACL используйте — это будет "просто лучше, чем ничего".

П[link18]од Linux существует так называемый "укреплённый chroot", в составе набора патчей, "повышающих безопасность". но разработчики ядра оценили этот проект как тупиковый и отказались включать его в ядро.

Знаете что? В гробу я видел ваш SELinux, песочницы, MAC, jail'ы, чруты, псевдовиртуалки и прочую нечисть. Есть механизмы контроля ОС (нет локального рута — нет утечки), и есть механизмы разделения информации между разными ОС через виртуалки (нет удалённого рута или дыры в самой виртуальной машине — значит, всё ОК). Всё остальное — это слишком сложные костыли, да ещё и толком не работающие, их изучение и использование себя не окупает, будет лишь иллюзия контроля и иллюзия безопасности. Я уже не говорю о том, что вопрос «откуда взять правила SELinux для такой-то моей конкретной задачи» практически нерешаем.
[/offtop]
Гость (25/05/2014 01:19)   
Распишите по шагам, как это сделать через SELinux...
Знаете что? В гробу я видел ваш SELinux, песочницы, MAC, ...

Прямо очередная истеричная баба с семью пятницами на неделе. Теперь понятно, почему берётся рассуждать об информационной безопасности не ведая элементарных азов. Надо будет дом построить — сколотит сарай без фундамента с односкатной крышей. Заявив, что в гробу видал долбатню со всеми этими премудростями. А нанять архитектора и строителя — религия не позволяет, это ведь денег платить придётся. Пусть ему лучше в инете, на борде анонимной, обрисуют весь необходимый ликбез на пальцах. Ну так, чтобы пять лет в строительном уложилось в два-три поста.
Гость (25/05/2014 01:51)   
Эмоций, срача, оскорблений, толстого троллинга и переходов на личности хватает, недостатка нет. А по существу ответ будет, как это сделать? Или мы имеем классический пример толстого троллинга от анонима, который пытается затроллить всех SELinux'ом при том, что он сам его в глаза ни разу не видел и никогда не настраивал?

Выше были приведены цитаты с мнениями тех, кто пытался с SELinux'ом разобраться. На эту тему в соответствующих топиках было много обсуждений. Получается, тут все кругом дебилы, никто не смог осилить, и только один вы — д'Артаньян? Тогда покажите это на деле.
Гость (25/05/2014 01:55)   

PGPru — это тематический форум, а не анонимная борда типа двача. Соответственно, ваши срачевбросы[link19], написанные в стиле «щас высрусь», могут быть снесены одним кликом, если не последует конструктив.
— pgprubot (28/08/2015 16:08, исправлен 28/08/2015 16:08)   

Один из способов перекидывания паролей/контента от одного юзера другому — это fifo:

userA $ mkfifo /tmp/file
userA $ cat filename > /tmp/file
userB $ cat /tmp/file
Юзер userB сделать cat сможет только один раз, т.е. достигается одноразовость передачи данных, и не нужно помнить, что файл надо стереть после чтения. Ещё бы там автостирание по таймауту было б — и совсем хорошо стало б.

— SATtva (28/08/2015 17:14)   
Уточнение: после создания FIFO-объекта следует изменить его права доступа, убрав общий доступ на чтение. В противном случае вместо userB перехватить данные сможет кто-нибудь другой.
— sentaus (28/08/2015 20:38)   
Уточнение уточнения: ещё лучше права доступа задать сразу при создании.
— SATtva (28/08/2015 22:28)   
Таки да. :)
— pgprubot (29/08/2015 19:06, исправлен 29/08/2015 19:23)   

Да, так будет ещё лучше, но есть нюанс — менять права доступа придётся под рутом, обычные юзеры этого делать не могут (chown, chgrp), т.е. тут и так уже между двумя юзерами приходится переключаться, а тут ещё и в рута придётся, чтоб сделать

# chgrp userB /tmp/file
# chmod o-rwx /tmp/file


Да, но userB об этом постфактум узнает, т.к. прочитать из fifo можно только один раз, доступ посторонних не останется незамеченным. ☺



А как? Есть[link21] способ с изменением на лету umask и с install, но это эквивалент chmod, а мне-то, получается, нужен эквивалент chgrp. Нашёл[link22] какой-то хак, но под обычным юзером он не работает:

userA $ sg userB -c "touch filename"
Password:
sg: failed to crypt password with previous salt: Invalid argument
Под рутом работают обе команды (sg и newgrp).

— SATtva (29/08/2015 22:17, исправлен 29/08/2015 22:17)   

Зачем? Минимальное требование только одно: юзеры A и B должны входить в одну группу, и права доступа должны быть ограничены чтением[/записью] в группе (-rw-rw----). То есть, как отметил sentaus, выполняйте

mkfifo -m o-rw /path

— pgprubot (29/08/2015 23:36, исправлен 30/08/2015 01:03)   

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

# usermod -a -G Xgroup userA
# usermod -a -G Xgroup userB
 
# [перелогиниваемся под обоими юзерами (userA и user B)]
# [проверяем:]
userA $ groups
group1 group2 groupN ... Xgroup
userB $ groups
group1 group2 groupN ... Xgroup
 
userA $ sg Xgroup -c "mkfifo -m o-rwx /tmp/fifo"
userA $ cat /path/to/file > /tmp/fifo
# [шелл вернётся только после чтения под userB]
 
userB $ cat /tmp/fifo


UPD: Если теперь всё замесить в скрипт, то под userA (передача односторонняя, от userA к userB) можно использовать script_name.sh типа такого:

#!/bin/sh
 
FILE=$1
FIFO_FILE=/tmp/name-of-your-fifo
GROUP_NAME=your_group_name
# e.g. Xgroup
 
FLAG=false
if ! [ -e $FIFO_FILE ] ; then
    sg $GROUP_NAME -c "mkfifo -m g=r,o-rwx \"$FIFO_FILE\""
    FLAG=true
elif [ -p $FIFO_FILE ] ; then
    if ! [ $(stat -c '%U' "$FIFO_FILE") = "$USER" ] ; then
        echo Wrong fifo owner
    elif ! [ $(stat -c '%G' "$FIFO_FILE") = "$GROUP_NAME" ] ; then
        echo Wrong fifo group
    else
        FLAG=true
    fi
fi
 
if $FLAG ; then
    cat $FILE > $FIFO_FILE
fi
Теперь для передачи содержимого файла /path/to/file_to_send из-под userA выполняем
$ script_name.sh /path/to/file_to_send
а под userB, получаетелем,
$ cat /tmp/name-of-your-fifo
Последнюю команду для удобства можно забить алиасом в конфиг шелла, чтоб не набирать каждый раз.

— sentaus (30/08/2015 11:46, исправлен 30/08/2015 11:47)   

Наверно можно ещё с ACL попробовать, но тут уже придётся создавать файл с правами rw только для себя, а потом с помощью setfacl дать права rw ещё и другому пользователю. Здесь не будет требования, чтобы они были в одной группе, но должна быть включена поддержка acl.


— pgprubot (13/10/2015 19:41, исправлен 13/10/2015 19:49)   

Не всегда требуется передавать именно файл — иногда надо просто какую-то ссылку или короткий текст, который вводится с консоли. В новом скрипте этот вариант также учтён:

#!/bin/sh
 
FIFO_FILE=/tmp/name-of-your-fifo
GROUP_NAME=your_group_name
# e.g. Xgroup
 
FLAG=false
if ! [ -e $FIFO_FILE ] ; then
    sg $GROUP_NAME -c "mkfifo -m g=r,o-rwx \"$FIFO_FILE\""
    FLAG=true
elif [ -p $FIFO_FILE ] ; then
    if ! [ $(stat -c '%U' "$FIFO_FILE") = "$USER" ] ; then
        echo Wrong fifo owner
    elif ! [ $(stat -c '%G' "$FIFO_FILE") = "$GROUP_NAME" ] ; then
        echo Wrong fifo group
    else
        FLAG=true
    fi
fi
 
if $FLAG ; then
    if [ $# -eq 0 ] ; then
        (while read inputline ; do
            if [ "${inputline}" = "EOF" ]; then
                exit
            fi
            echo "${inputline}"
        done) > $FIFO_FILE
    else
        cat $1 > $FIFO_FILE
    fi
fi
Передача файлов работает, как и раньше. Для передачи текста скрипт запускается без аргументов:
$ /path/to/script_name.sh
text of line1
text of line2
EOF
Под принимающем пользователем:
$ cat /tmp/name-of-your-fifo
text of line1
text of line2


Ссылки
[link1] http://www.keepassx.org/

[link2] http://keepass.info/

[link3] https://www.pgpru.com/comment59834

[link4] https://www.pgpru.com/comment64413

[link5] https://www.pgpru.com/comment64648

[link6] https://www.pgpru.com/comment68176

[link7] https://www.pgpru.com/comment68223

[link8] https://www.pgpru.com/comment38574

[link9] https://www.pgpru.com/comment38599

[link10] https://www.pgpru.com/comment48294

[link11] https://www.pgpru.com/comment21230

[link12] https://www.pgpru.com/comment32257

[link13] https://www.pgpru.com/comment52979

[link14] https://www.pgpru.com/comment69008

[link15] https://www.pgpru.com/comment60120

[link16] https://www.pgpru.com/comment67944

[link17] https://www.pgpru.com/comment34765

[link18] https://www.pgpru.com/comment34713

[link19] https://www.pgpru.com/comment79837

[link20] https://www.pgpru.com/comment93921

[link21] https://unix.stackexchange.com/questions/47178/can-files-be-created-with-permissions-set-on-the-command-line

[link22] https://stackoverflow.com/questions/1321168/bash-scripting-how-to-set-the-group-that-new-files-will-be-created-with