Реальным идентификатором пользователя данного процесса является идентификатор пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа процесса к системным ресурсам (в первую очередь к ресурсам файловой системы). Обычно реальный и эффективный идентификаторы совпадают, т.е. процесс имеет в системе те же права, что и пользователь, запустивший его. Однако существует возможность задать процессу более широкие права, чем права пользователя, путем установки бита SUID , когда эффективному идентификатору присваивается значение идентификатора владельца выполняемого файла (например, пользователя root ).
Реальный (GID) и эффективный (EGID) идентификаторы группы
Реальный идентификатор группы равен идентификатору основной или текущей группы пользователя, запустившего процесс. Эффективный идентификатор служит для определения прав доступа к системным ресурсам от имени группы. Обычно эффективный идентификатор группы совпадает с реальным. Но если для выполняемого файла установлен бит SGID , такой файл выполняется с эффективным идентификатором группы-владельца.
Атрибуты файлов
Аннотация
Аналогично файловой системе FAT, имеющей атрибуты файлов (архивный, системный файл, скрытый), в файловой системе ext2fs также имеются свои собственные, но они отличаются. Мы вкратце пройдемся по ним для полноты повествования, но используются они очень редко. Однако, если вы действительно хотите получить защищенную систему - читайте дальше.
Существует две команды для управления атрибутами файла: lsattr(1) и chattr(1) . Вы, наверное, догадались, что команда lsattr выводит список (LiSt) атрибутов, а команда chattr изменяет (CHange) их. Эти атрибуты могут быть установлены только для каталогов и обычных файлов. Доступны следующие атрибуты:
1. A («no A ccess time»): если для файла или каталога установлен этот атрибут, то, всякий раз при обращении к нему для чтения или записи, у него не будет обновляться время последнего доступа. Это может быть полезно, например, для файлов и каталогов, к которым очень часто обращаются для чтения, особенно из-за того, что это единственный параметр в inode, который изменяется при открытии файла только для чтения.
2. a («a ppend only»): если для файла установлен этот атрибут, и этот файл открыт для записи, то единственной доступной операцией будет добавление данных к его предыдущему содержимому. Для каталога это означает, что вы сможете только добавить файлы, но не сможете переименовать или удалить ни одного из существующих файлов. Только root может установить или снять этот атрибут.
3. d («no d ump»): dump (8) - это стандартная утилита UNIX ® для резервного копирования. Она делает дамп любой файловой системы, для которой счетчик дампов в файле /etc/fstab (5-е поле) равен 1 (см. главу Глава 8, Файловые системы и точки монтирования ). Но если этот атрибут установлен для файла или каталога, то он, в отличие от других, будет будет пропущен при снятии дампа. Обратите внимание, что при установке его для каталогов, это также распространяется на все их подкаталоги и файлы.
4. i («i mmutable»): файл или каталог с установленным этим атрибутом вообще не может быть изменен: он не может быть переименован, на него не может быть создана ссылка и он не может быть удален. Только root может установить или снять этот атрибут. Обратите внимание, что это также предотвращает изменение времени последнего доступа, поэтому вам нет необходимости устанавливать атрибут A , если установлен i .
5. s («s ecure deletion»): когда удаляется файл или каталог с этим атрибутом, блоки, которые он занимал на диске перезаписываются нулями.
6. S («S ynchronous mode»): если для файла или каталога установлен этот атрибут, все его изменения синхронизируются и немедленно записываются на диск.
К примеру, вы можете установить атрибут i на жизненно важные системные файлы, чтобы избежать неприятных сюрпризов. Также, рассмотрите вариант установки атрибута A на страницы руководств: это позволит избежать многих дисковых операций, и, в частности, может немного продлить жизнь аккумуляторов портативных компьютеров.
15.Порождение процессов в системе
– Игорь (Администратор)В данной статье для начинающих пользователей, я расскажу вам о том, что такое ID и UID, для чего они применяются и как используются.
Практически в любой сфере используется какой-то отличительный атрибут для выделения одного человека среди других. Так как без этого весьма сложно было бы вести хоть какой-либо учет. И речь идет не только об интернете или социальных сетях. Поэтому первым делом рассмотрим определение.
ID (от Identifier) - это произвольного вида идентификатор индентификатор. Он может состоять как из цифр, так и из букв со спецсимволами. К примеру, в личных документах это могут быть серия и номер, в документах вещей это могут быть цифро-буквенные комбинации по типу "KDSGEW-1441-3215". Если брать более жизненный пример, то ваши фамилия, имя и отчество так же являются вашим идентификатором.
Стоит понимать, что хоть в интернете ID чаще всего является уникальным, как таковым, он не обязан быть. К примеру, в мире всегда могут существовать ваши полные тески. В случае, если требуется уникальность, то корректно называть UID. Рассмотрим определение.
UID (от unique identifier) - это уникальный идентификатор. Так же может состоять из произвольного набора символов, однако его отличительной особенностью является то, что он никогда не повторяется. Другими словами все, что подвержено учету, всегда можно четко идентифицировать по этому UID, без возможных путаниц.
Для чего применяются ID и UID? Чтобы легче было понять. Попробуйте себе представить, что вы стоите в поле среди тысячи людей. И вам нужно позвать одного человека, чтобы он пошел трактор чинить. Если бы у людей не было ФИО, то для того, чтобы найти соответствующего человека, вам нужно было говорить что-то вроде "Такой вот, такового вот роста, с такими вот усищами, с такими то отличительными особенностями, ..." и так тысячу раз, при этом каждый бы переспрашивал и уточнял детали. Когда же вы зовете по имени, то ситуация быстрее решается.
Однако, многие все же привыкли соотносить идентификаторы именно с областью информационных технологий, включая интернет. И в этом нет ничего удивительного, так как сегодня практически у каждого есть свой собственный личный компьютер с доступом в сеть. Соответственно, и тут ID и UID не сильно отличаются. Они применяются для быстрого поиска необходимой информации, например, в социальных сетях у каждого пользователя есть идентификатор, который видно в адресе страницы профиля. Зная этот идентификатор вы всегда можете быстро найти страничку пользователя (без поиска среди десятка тесок).
Стоит знать, что в ИТ в большинстве своем идентификаторы представляют собой целые числа, так как чисто технически операции поиска с числами выполняются быстрее.
Теперь, вы знаете что такое ID и UID, как их используют и для чего они применяются.
Непосвящённому клиенту Сбербанка сложно разобраться в понятии СУИП. Что это такое в платежном поручении? Для чего нужен этот дополнительный номер? Если говорить понятным языком, то это идентификатор каждого конкретного платёжного документа в электронном варианте . Буква «У» означает уникальный. Совершая любое платёжное действие, вы получаете чек, в котором к прочим данным добавляется набор цифр и букв, который и является идентификатором вашего платежа.
Почему появился СУИП
В марте 2014 любое платёжное поручение начало получать собственный идентификатор. УИН применяется, когда речь идёт о платежах в бюджет РФ. УИП – это идентификатор других платежей. И УИН, и УИП состоят из 20-ти цифр.
Уникальный идентификатор платежа (поле 22)
Исходя из вышесказанного, можно понять, что такое СУИП в чеке Сбербанка. Буква «С» означает название банка. Таким образом Сбербанк сможет идентифицировать любой сделанный в его электронной системе платёж.
Сбербанковский идентификатор состоит из 16-ти знаков. Из них, первые 12 – это комбинация цифирных знаков, последующие 4 – заглавные буквы английского алфавита.
Важно знать, как проверить уникальный номер платежа СУИП Сбербанк. Он указывается в каждом электронном чеке . Примерно в середине квитанции вместе с суммой и данными о кошельке плательщика. СУИП Сбербанк – это номер, имеющий отношение к электронной платёжной системе.
Зачем нужен уникальный номер
Ежедневно миллионы людей осуществляют электронные платежи через Сбербанк. Что делать, если система дала сбой, и платёж не прошёл? Деньги могли пойти не туда и из-за ошибки в реквизитах, возможно, счёт, на который их отправили, больше не существует.
Важно получить не только ответ на вопрос «Уникальный номер платежа СУИП Сбербанк — что это?», но и понять, что, сохранив квитанцию или переписав данный номер, вы сможете найти свои деньги, куда бы они ни попали либо сделать так, чтобы они пошли по назначению.
Потребность в уникальном электронном номере возникла в связи с большим потоком денежных средств и необходимостью их отслеживания. Сохранив квитанцию, вы сможете, в случае обращения в любой офис Сбербанка или в компанию, куда осуществляли перечисление, найти свой платёж. Это может относиться и к коммунальным службам, и к социальным сетям, и к интернет-магазинам, и к любому другому платежу. СУИП даёт возможность систематизировать денежный поток и выбрать из него нужное.
Э та статья по основам Linux научит вас всему важному, связанному с UID в Linux.
Что такое UID в Linux?
UID обозначает идентификатор пользователя. UID – это номер, назначенный каждому пользователю Linux. Это представление пользователя в ядре Linux.
UID используется для идентификации пользователя в системе и для определения того, к каким системным ресурсам пользователь может получить доступ. Вот почему идентификатор пользователя должен быть уникальным.
Вы можете найти UID в файле /etc/passwd. Это тот же файл, который можно использовать для составления списка всех пользователей в системе Linux.
Используйте команду Linux для просмотра текстового файла, и вы увидите различную информацию о пользователях, присутствующих в вашей системе.
Root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin andreyex:x:1000:1000:Andrey,:/home/helder:/bin/bash davmail:x:127:65534::/var/lib/davmail:/usr/sbin/nologin statd:x:128:65534::/var/lib/nfs:/usr/sbin/nologin
Третье поле здесь представляет идентификатор пользователя или UID.
Обратите внимание, что в большинстве дистрибутивов Linux UID 1-500 обычно зарезервирован для системных пользователей. В Ubuntu и Fedora UID для новых пользователей начинаются с 1000.
Например, если вы используете команду для создания нового пользователя, он получит следующий доступный номер после 1000 в качестве своего UID.
Корневой пользователь
В Linux UID – 0 и GID – 0 зарезервированы для пользователя root.
Как найти UID пользователя в Linux?
Вы всегда можете положиться на файл /etc/passwd, чтобы получить UID пользователя. Это не единственный способ получить информацию UID в Linux.
Команда id в Linux отобразит UID, GID и группы, к которым принадлежит ваш текущий пользователь:
Id uid=1000(andreyex) gid=1000(andreyex) groups=1000(andreyex),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lpadmin),126(sambashare),127(kvm)
Вы также можете указать имена пользователей с помощью команды id, чтобы получить UID любого пользователя Linux:
Id standard uid=1001(standard) gid=1001(standard) groups=1001(standard)
Как изменить UID пользователя в Linux?
Предположим, у вас было несколько пользователей в вашей системе Linux. Вы должны были удалить пользователя, потому что он/она покинул организацию. Теперь вы хотите, чтобы его UID был занят другим пользователем, уже находящимся в системе.
Вы можете изменить UID, изменив пользователя с помощью команды usemod следующим образом:
Usermod -u 1004 user_2
Вы должны иметь привилегию суперпользователя для выполнения вышеуказанной команды.
Вы помните концепцию ? Право собственности на файл определяется UID пользователя-владельца.
Когда вы обновляете UID пользователя, что происходит с файлами, принадлежащими этому пользователю? В то время как все файлы в домашнем каталоге user_2 изменят свой связанный UID, вам придется вручную обновить связанный UID других файлов вне домашний каталог.
Что вы можете сделать, это вручную обновить владельца файлов, связанных со старым UID пользователя_2.
Find / -user old_uid_of_user_2 -exec chown -h user_2 {} \;
Вот и все. Мы надеемся, что теперь у вас есть лучшее представление об UID в Linux. Не стесняйтесь задавать свои вопросы, если таковые имеются.
Как профессиональный пользователь Linux, если вы думаете, что мы пропустили какое-то важное понятие об UID, пожалуйста, дайте мне знать в разделе комментариев.
Добрый день, Хабр!
Мы хотим сделать обзорный пост, посвящённый нашему новому проекту. Обзор затронет как функционал, так и техническую часть, надеемся, это сделает статью интересной как профессиональным разработчикам, так и тем, кто читает Хабр с целью держать руку на пульсе Технологии.
Тем, кому интересна только техническая сторона проекта - рекомендуем сразу перейти ко второй части .
ЧАСТЬ 1. Лирическая
Мы - это команда разработки сервиса личных страниц uid.me .
Личная страница - это, например, вот так:
http://uid.me/pavel_kudinov
Тем, кто не знаком с западным аналогом нашего сервиса, следует признаться: проект uid.me начинает свою историю как клон-локализация англоязычного сервиса about.me
История создания
Дело было так. Компания сайт-билдер uCoz, в которой мы трудимся, за 8 лет существования накопила в недрах своих дата-центров более 35 млн профилей, созданных веб-мастерами, а также многочисленными посетителями созданных веб-мастерами сайтов, форумов и блогов.
Всех этих людей объединяет глобальная система авторизации uID:
До сегодняшнего дня каждый человек, зарегистрированный в uCoz, имел профиль такого вида:
Проект about.me был выбран как лучший существующий прототип индивидуальной страницы для каждого пользователя uCoz, отвечающий, на наш взгляд, современному тренду самовыражения обитателей Сети начала XXI века.
Как и в случае about.me , мы даём пользователю:
1. Ставший правилом хорошего тона URL вида uid.me/имя_фамилия , который вполне можно использовать для печати на визитной карточке, указать в качестве домашней страницы в skype, а также упоминать на любом медиа-носителе.
2. Возможность объединить в единый визуальный образ личное фото, фоновое изображение в высоком разрешении, основную информацию о себе (такую как биография и сфера интересов).
3. Конструктор, с помощью которого можно быстро и увлекательно придать своей личной странице уникальный вид и общую визуальную согласованность.
4. И, наконец, самое интересное: сегодня многие из нас активно присутствуют в социальных сетях. Кому-то ближе форматы Facebook и Вконтакте, кто-то ограничивается микроблогами Twitter и Instagram, кое-кто имеет свой популярный канал на Youtube.
И здесь справедливо правило - чем большую социальную активность проявляет человек, тем острее встаёт вопрос: “какую из социальных сетей считать “главной”?”.
Мы предлагаем использовать uid.me в качестве своеобразной личной визитной карточки онлайн. Наш сервис позволяет привязать к собственному профилю наиболее распространённые социальные сети, и тогда не придётся выбирать - какую именно ссылку дать при новом ценном знакомстве, указать в профиле skype или поставить в подпись на форуме.
Ваши посты, твиты и фотографии будут автоматически появляться в вашем профиле, причём для отображения будет использован общий вид, а функция “поток” создаст общую ленту событий, объединяя в хронологическом порядке всё происходящее с вами.
Кстати, если вы захотите создать личную страницу на uid.me , рекомендуем воспользоваться автоматической регистрацией через социальную сеть. При клике по любой из кнопок “Войти через ” - личная страница будет мгновенно создана без необходимости вводить регистрационную информацию!
Забегая вперёд, хотим сказать, что тесная интеграция с социальными сетями в ближайшем будущем существенно сместит план развития проекта.
Вторая версия профилей uid.me , уже находящаяся в разработке, будет иметь главный фокус именно на функции объединения информации из социальных сетей в единый поток с настраиваемым представлением данных.
В дополнение планируется разработать несколько интересных инфографических виджетов в виде красочных графиков и диаграмм, представляющих информацию о ваших друзьях, путешествиях, музыкальных предпочтениях и прочие интересные занимательные факты, которые система сумеет извлечь из ваших профилей и обработать автоматически.
Возможно, это будет выглядеть как-то так:
ЧАСТЬ 2. Техническая
Разрабатывая uid.me под крылом uCoz, мы оказались в довольно необычном положении: с одной стороны, весь код проекта предполагалось написать с чистого листа, с другой стороны, в день релиза проект автоматически становился высоконагруженным, так как должен был импортировать в себя более 20 млн профилей, даже с учётом того, что бот-регистрации и совсем уж древние профили не прошли конкурс.
Тем не менее, мы решили сделать всё красиво и с использованием модных технологий, проведя таким образом разведку боем, получив много опыта и потенциальный левелап в итоге.
В качестве слагаемых успеха были выбраны:
0. Nginx. Куда без него.
1. База данных, из коробки решающая вопрос распределения данных на несколько серверов + отказоустойчивость при физическом выпадении сервера из кластера по любой причине. В этом качестве, несмотря на активные холивары, была выбрана MongoDB.
2. Гибкая схема данных, позволяющая без потерь проходить первичную и последующие фазы прототипирования функционала. Опять же помог MongoDB, хотя здесь пришлось заплатить ресурсами за удобство, так что получить главный ответ на вопрос: “BSON - это роскошь, или современное средство передвижения?” - ещё предстоит.
Стоит заметить, что исходная mysql база данных пользовательских профилей при конвертации в MongoDB формат выросла в 5 раз. Однако, каждый профиль при этом обогатился внушительным количеством новых данных, связанных с функционалом uid.me , поэтому дело не только в прожорливости гибкой схемы данных BSON.
3. Честно говоря, учитывая современную тенденцию к активному применению динамических JS интерфейсов (а также безмерное уважение к технологическому прорыву, сделанному инженерами Google при разработке V8 Javascript, на порядок обходящему по производительности все существующие скриптовые языки за счёт динамической компиляции в машинный код), закралась шальная мысль применить node.js и замкнуть круг веб-разработки на JavaScript, получив вместе с тем несколько жирных плюшек…
Но решили, что “один проект - одна новая технология, и нам пока что MongoDB ВОТ ТАК хватает ” (с) Александр Соловьев. Кстати, кто не видел этот его доклад - это хит, рекомендуем всем коллективом!
В итоге, в качестве серверной технологии решили оставить корпоративно-привычный Perl, однако нам удалось набрать вторую космическую скорость, покинуть гравитационное поле fast_cgi и применить Mojolicious - современный автономный и адекватный (не считая автора) веб-фреймворк с роутами, хелперами, бриджами, встроенной поддержкой асинхронных запросов и прочими положенными современному разработчику сладостями.
4. Тотальная асинхронность и кеширование данных при взаимодействии с социальными сетями.
К слову о прототипе проекта - было замечено, что данные из социальных сетей, полученные сервисом about.me, не обновляются, загружаясь лишь единожды - в момент подключения сервиса. Вероятно, опция обновления кеша доступна VIP пользователям, но нам не удалось добиться от about.me обновления информации. Это навело нас на мысли о том, что стоит по возможности как можно более качественно организовать межсерверное взаимодействие и систему кеширования, чтобы минимизировать риск возникновения схожих проблем в будущем.
Практически повсеместно внедрённый OAuth2 и схожесть в организации API различных социальных сетей дали возможность удачно обобщить взаимодействие.
Конечно, на этапе прототипа вся работа с API была синхронной, но блокировать Hypnotoad воркеры для осуществления API запросов в высоконагруженном проекте - однозначная роскошь и расточительство. К счастью, Mojolicious построен на весьма приличной, как по интерфейсу, так и по реализации, событийной машине, благодаря чему, кстати, каждый воркер в пуле способен параллельно обрабатывать не один (как в случае, скажем, с mod_perl), а десятки параллельных запросов, конечно, при условии, что те содержат значимое количество асинхронного кода.
К слову, учитывая то, что одним из основных “пугающих” аргументов против примененияnode.js является его тотальная асинхронность, - Mojolicious может послужить отличным ментальным мостом, когда вы начнёте разработку в рамках классической синхронной парадигмы, а закончите, как минимум, имея значительную часть гибридного кода (sync + async). Признаться, теперь мы боимся node.js значительно меньше и надеемся применить его в последующих проектах.
Вообще, uid.me делался по принципу “нет велосипедам”, и в жертву Шиве был торжественно принесён целый пласт ископаемых самоделок, возглавляемый широко известным в узких кругах килобайтным макросом “dw ”, с 2005 года верой и правдой служивший нам и близким нам разработчикам и позволивший в трудный час избежать трансцендентного ужаса DBIx::Class. Светлая память.
И всё же, при разработке uid.me родилась одна занимательная поделка - это макрос
Take { … $take->(‘named_callback_slot_1’) ... } process { my $taken = shift; … },
Построенный на Mojo::IOLoop->delay и радикально упрощающий весь цикл операций, связанных с организацией именованных каскадных асинхронных API взаимодействий, включая каскадную обработку исключений (при возникновении интереса - пишите в личное, поделимся).
Возвращаясь к MongoDB
Применить на практике что-то похожее на NoSQL решение хотелось ещё с тех времён, когда это не было мейнстримом. В рамках тех highload задач, с которыми в то время приходилось сталкиваться, постепенно нарисовалось следующее понимание:
1. Классический LAMP проект стартует с классической SQL БД.
2. Если проект становится популярным, он обретает статус «highload», иначе goto 1.
3. Статус «highload» обязывает нас вплотную задуматься о кешировании, шардировании, репликации и
бекапе того, что хранится в SQL БД.
4. Эволюция схемы данных живого проекта становится тем более болезненной, чем больше данных накоплено, и тем более востребованной, чем более популярным оказался проект.
5. В результате всего этого ORM код начинает выполнять функции mutex, сериализации/десериализации данных для memcached, примитивного шардирования, в особо жестоких ситуациях - патчи обеспечения обратной совместимости схемы данных (ибо позволить себе большой сквозной апдейт данных в реальных условиях удавалось далеко не всегда).
Впрочем, довольно о грустном, на дворе были суровые 2000"е.
Начало 2010"х было озарено появлением нескольких NoSQL решений, которые обещали устранить бОльшую часть проблем растущего highload проекта «из коробки». Появление открытых, готовых к использованию NoSQL решений пророчили многие, но, тем не менее, фактическое обретение прекрасного будущего нас приятно удивило.
Посоветовавшись с более экстремальными в плане новшеств коллегами, мы решили пробовать MongoDB .
Изучая новую для себя технологию, мы посчитали логичным применить её возможности по максимуму, надеясь на лучшее (а значит, на серебряную пулю из коробки), рассчитывая, впрочем, откатиться к более классическим техникам в тех местах, где чрезмерная наглость столкнула бы нас с интересными подводными камнями.
Под применением возможностей по максимуму мы подразумеваем следующее:
1. JSON формат хранения данных позволил не возиться с привычными parent/child/x-связями в схеме данных по поводу и без, ограничившись здравым смыслом. В результате вложенная структура основного объекта user оказалось жирной, но удобной. В неё смело вложили кучу флажков, настроек отображения, мелких связанных списков и всего того прочего, что раньше с ходу приводило к созданию пачки около-user"овых SQL таблиц.
2. В модель данных добавили код общего назначения, который на этапе прототипирования интерфейса позволил крайне приятно наращивать JS функционал: по URL /profile/save стало возможным послать любой JSON, который extend"ил объект пользователя новыми данными, например:
User.save({ "style.profile.top": "20px", "style.caption.tags.color": "rgba(30, 29, 38, 1)", "info.first_name": "Павел" });
Все операции, связанные с деятельностью авторизованного пользователя были упакованы в общую функцию отправки с латентным коллектором в 500 мсек, объединяющим различные атомарные правки в общие пакеты.
В результате, client-side разработчики смогли легко расширять структуру объекта user, просто начиная использовать новые поля.
Конечно, после фазы прототипирования, серверная часть /profile/save была снабжена контекстными фильтрами данных, которые отсекали неизвестные поля и фильтровали значения на предмет корректности.
Осталась только одна проблема - в БД могли храниться пользователи, у которых вообще не существовали некоторые поля, так как последний раз они редактировали свой профиль ещё до того, как эти поля возникли. В идеале, хотелось бы иметь default-значения для каждого поля, которые будут магическим образом появляться в любом объекте, извлекаемом из БД.