VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ
BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMAČNÍCH TECHNOLOGIÍ
ÚSTAV INFORMAČNÍCH SYSTÉMŮ
FACULTY OF INFORMATION TECHNOLOGY
DEPARTMENT OF INFORMATION SYSTEMS
TOOL FOR QUERYING SSSD DATABASE
BAKALÁŘSKÁ PRÁCE
BACHELOR’S THESIS
AUTOR PRÁCE
AUTHOR
BRNO 2013
DAVID BAMBUŠEK
VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ
BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMAČNÍCH TECHNOLOGIÍ
ÚSTAV INFORMAČNÍCH SYSTÉMŮ
FACULTY OF INFORMATION TECHNOLOGY
DEPARTMENT OF INFORMATION SYSTEMS
NÁSTROJ PRO DOTAZOVÁNÍ SSSD DATABÁZE
TOOL FOR QUERYING SSSD DATABASE
BAKALÁŘSKÁ PRÁCE
BACHELOR’S THESIS
AUTOR PRÁCE
DAVID BAMBUŠEK
AUTHOR
VEDOUCÍ PRÁCE
SUPERVISOR
BRNO 2013
Doc. Dr. Ing. DUŠAN KOLÁŘ
Abstrakt
Tato práce je zaměřena na databáze a konkrétně pak na databázi SSSD. SSSD je služba,
která poskytuje jedno kompletní rozhraní pro přístup k různým vzdáleným poskytovatelům
a ověřovatelům identit spolu s možností informace z nich získané ukládat v lokální cache
k offline použití. Práce se zabývá jak databázemi obecně, tak pak hlavně LDAP a LDB,
které jsou použity v SSSD. Dále popsuje architekturu a samotnou funkci SSSD. Hlavním
cílem pak bylo vytvořit aplikaci, která bude administrátorům poskytovat možnost prohlížet
všechna data uložená v databázi SSSD.
Abstract
This thesis is focused on databases, particularly on SSSD database. SSSD is a set of
daemons providing an option to access various identity and authentication resources through
one simple application, that also offers offline caching. Thesis describes general information
about databases, but mainly focuses on LDAP and LDB, that are used in SSSD. In addition
also describes function and architecture of SSSD. Main goal of this thesis was to create a
tool, that will be able to query all the data stored in SSSD database.
Klíčová slova
Databáze, LDAP, LDB, SSSD, Red Hat, dotazovací nástroj
Keywords
Databases, LDAP, LDB, SSSD, Red Hat, querying tool
Citace
David Bambušek: Tool for querying SSSD database, bakalářská práce, Brno, FIT VUT
v Brně, 2013
Tool for querying SSSD database
Prohlášení
Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně pod vedením pana Doc.
Dr. Ing. Dušana Koláře
.......................
David Bambušek
May 14, 2013
Poděkování
Velice rád bych poděkoval vedoucímu mé bakalářské práce Doc. Dr. Ing. Dušanovi
Kolářovi, který mi poskytl cenné pedagogické a věcné rady k vypracování mé práce. Stejně
velký dík patří odbornému konzultantovi Ing. Janu Zelenému, za všechny potřebné rady a
informace, které mi pomohly k úspěšnému vypracování mé práce. Na místě je také poděkovat firmě Red Hat, která mi umožnila vypracovávat práci pod její záštitou, stejně tak jako
všem jejím zaměstancům, hlavně paktýmu SSSD pod vedením Ing. Jakuba Hrozka, kteří
se podíleli na revizi mého kódu a poskytovali další věcné rady a doporučení.
c David Bambušek, 2013.
Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení
oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.
Contents
1 Introduction
3
2 Introduction to Databases
2.1 Relational Database . . . . . . . .
2.1.1 Overview and Terminology
2.1.2 Relational Model . . . . . .
2.1.3 Structure . . . . . . . . . .
2.1.4 Constrains . . . . . . . . .
2.2 Tree Databases . . . . . . . . . . .
2.2.1 XML Databases . . . . . .
2.3 Other Databases . . . . . . . . . .
2.3.1 NoSQL . . . . . . . . . . .
2.3.2 Object Oriented Databases
3 Directory Services
3.1 LDAP . . . . . . . . . . . . . .
3.1.1 Name Model . . . . . .
3.1.2 Informational Model . .
3.1.3 Functional Model . . . .
3.1.4 Security Model . . . . .
3.1.5 LDIF . . . . . . . . . .
3.1.6 LDAP Usage . . . . . .
3.1.7 LDAP Implemantations
3.2 LDB . . . . . . . . . . . . . . .
3.2.1 TDB & DBM . . . . . .
4 SSSD
4.1 User Login in Linux .
4.1.1 Identification .
4.1.2 Authentication
4.1.3 Problems Using
4.1.4 SELinux . . . .
4.2 Basic Function . . . .
4.3 Architecture . . . . . .
4.3.1 Processes . . .
4.3.2 Communication
. . .
. . .
. . .
NSS
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . .
. . . . . .
. . . . . .
and PAM
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
5
5
6
6
7
8
8
10
10
12
.
.
.
.
.
.
.
.
.
.
14
15
15
16
17
18
18
19
19
19
20
.
.
.
.
.
.
.
.
.
21
21
21
21
21
22
22
23
23
24
5 SSSD Database
5.1 Users . . . . . .
5.2 Groups . . . . .
5.3 Netgroups . . .
5.4 Services . . . .
5.5 Autofsm Maps
5.6 Sudo Rules . .
5.7 SSH Hosts . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Querying Tool
6.1 Program Specification . . . . . . . . . . . .
6.2 Basic Information and User Interface . . . .
6.3 Application Architecture . . . . . . . . . . .
6.4 Tool Design . . . . . . . . . . . . . . . . . .
6.5 Implementation . . . . . . . . . . . . . . . .
6.5.1 Initialization . . . . . . . . . . . . .
6.5.2 Query on Basic Objects . . . . . . .
6.5.3 Domain and Subdomain Information
6.5.4 Printing Results . . . . . . . . . . .
6.5.5 Errors . . . . . . . . . . . . . . . . .
6.6 Tests . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
26
27
27
28
.
.
.
.
.
.
.
.
.
.
.
29
29
29
31
32
32
32
33
34
34
35
35
7 Conclusion
36
A DVD contents
38
B Manual
B.1 Unpacking . . . .
B.2 Dependencies . .
B.3 Compiling . . . .
B.4 Exemplary data .
B.5 Running the tool
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
40
40
40
C Man page
41
D Errors
43
E Application Constants, Flags and Arguments
45
F Test results
47
2
Chapter 1
Introduction
Today, thanks to the Internet, society has become one global connected network of people,
where the most important thing that makes people powerful is knowledge, in other words
information. Unfortunately people are not able to store all the information they know in
their own brains and therefore we are forced to use computers to help us with this task.
For purposes of storing huge quantities of information that we need, we created computer
databases.
Databases can store various types of data, reflecting real models from our world or can
store purely abstract data. To identify ourselves on the Internet or any other networks, we
use virtual profiles, that store data about ourselves and about our membership in certain
groups or companies. This thesis describes a tool, that is able to query such a database
of users and additional information provided for managing virtual identity. Particularly
it is an SSSD database. SSSD is a set of daemons providing an option to access various
identity and authentication resources through one simple application, that also offers offline
caching.
In chapter two, we will look generally on various existing types of databases and make
more detailed description of the most used one, that is relational database.
Chapter three is focused on directory services - LDAP and LDB, which is not directory
service by itself, but it is an abstract layer over lower key-value types of databases, offering
LDAP-like API. LDB is the database used in SSSD.
In chapter four we will take a closer look on SSSD itself, we will introduce basic purpose,
function and architecture and in chapter five a complete description of a SSSD database
will follow.
The sixth chapter describes the tool for querying SSSD databases, there we will find a
complete architecture of this application, its UI and examples of usage.
Conclusion and development will be stated in the last seventh chapter.
3
Chapter 2
Introduction to Databases
This chapter widely derives from sources [1] and [6]. Term database can be understood as
a set or collection of data, that is somehow organized. It is typical, that a database reflects
a real existing concept, system, structure or information, under which we can imagine for
example cities and their populations, company employees or items in a store. We can work
with this database and store, change, delete or query information stored in it.
To work with a database, we use a database management system (DBMS), what is a
software allowing us to run all mentioned operations and to administrate the database.
Most known and widely used DBMS are for sure MySQL, SQLITE, Microsoft Access or
PostgreSQL.
When speaking about database, we usually understand this term as both data and their
structure so as database management system, but formally database“ is just data wired
”
to its data structures.
We can divide function of DBMS into four groups:
1. Data control - maintaining integrity, taking care of security, monitoring, dealing with
permissions to work with a database (creating and managing users)
2. Data definition - creating/modifying/removing data structures to/from a database
3. Data maintenance - inserting/updating/deleting data from a database
4. Data retrieval - data mining done by users to work with received information or to
proceed it for other purposes by querying and analyzing
Each database with its DBMS works and looks accordingly to its database model. We will
get back to each type in next subsections, for now to mention them, they are historically
divided to three major groups: navigational, relational and post relational databases.
During first era in 1960’s, there were two main representants of navigational model:
hierarchical model developed at IBM and the Codastl(Network) model. Navigation in
Codastyl was based on linked data creating huge network. It was possible to search for
entries using their primary key(CALC key), by using relationships from one entry to another
or by going through all entries sequentially. IBM’s DBMS IMS was quite similar to Codastl,
but instead of network model it used stricter hierarchical model.
In 1970’s the world first encountered relational DBMS, which was introduced by Edgar
Codd from IBM, more detailed description will be offered in next section. Main difference
is that a database is formed from tables, each used for different entity. Main idea in terms
of how to search for entries is that we should search data by content and not by following
4
links as it was with navigational databases. Relational databases became the most used
types of databases and have persisted on that spot until now. The dominant language used
to work with them is SQL.
So far last era of databases, called post-relational, showed up at the dawn of new
millennium. These databases are document-oriented and offer quick key-value storage.
They are mostly used in situations when we store large quantity of information and where
the relationship between them is not that important. These databases found their place at
social networks like Facebook or Twitter to store comments, tweets and other mass quantity
information.
Languages used for communication with databases have each its own specific function:
• Data definition languages - define data types and their relationships
• Data manipulation languages - used for inserting/updating/deleting data
• Query languages - used for searching for data
Each database model has its own language. Most know and used languages are, already
mentioned, SQL, then OQL used in object model databases or XQuery used with XML
databases.
2.1
2.1.1
Relational Database
Overview and Terminology
As the book states [1]. A relational database is a set of data entries that are organized
as a collection of tables. Relational database is created upon a basis of relational model
and a software to operate this database is called a relational database management system
(RDBMS). It is nowadays the most used type of database that can satisfy needs for solutions
of most common problems and can be applied on most models that can be found in our
world. The most simplified view on relational database is that it consists of tables, that
are composed of rows, where each field represents one of attributes.
Relational database theory is a mathematical theory and it has its own terminology,
these terms are slightly different from those terms, that we use when talking about SQL,
which is the main language operating with relational databases. Table 2.1 shows the differences.
mathematical theory
relation, base relvar
tuple
attribute
attribute value
derived relvar
SQL
table
row
column name
column data
query result
Table 2.1: mathematical vs. SQL terminology
5
2.1.2
Relational Model
The basic idea of relational model is that all data is mathematically represented as n-ary
relations, which are subsets of a cartesian product of n domains. The view on data in
this mathematical model is done by two-valued predicate logic, where each proposition can
be either true or false (later there were attempts to change this to three or four valued
predicate logic by adding unknown value and then valid an invalid unknown). Data are
handled due to rules of relational algebra or a relational calculus.
Each relational database has constraints, which lead its designer to create a consistent
representation of some information model. The process of creating consistent database is
called normalization, which leads to selection of most suitable logically equivalent alternative of the database.
Basic building stone of a relational database is domain, usually referred as type. Tuple,
that is ordered set of attributes. Attribute consists of attribute name and data type name.
Every relation is composed from a heading and a body. Heading is a collection of attributes
and body is the rest, meaning a set of n-tuples. Relation, which is visualized as a table,
consists of a set of n-tuples, tuple is then similar to a row. Relvar is a specific relation type
variable, it is used to differentiate between a variable containing relation and relation itself.
This model was introduced to world by E.F.Codd, who worked in IBM’s San Jose
Research Laboratory in 1970’s. Later other people as Chris Date and Hugh Darwen with
their teams were the ones who developed and maintained relational model. Codd made
his 12 rules“ (in fact 13, because they are numbered from zero to 12) to define what a
”
database management system must fulfill in order to be accepted as relational. But in fact,
none of used RDBMS nowadays comply to all 13 rules, the only example which does is
Dataphor.
2.1.3
Structure
When speaking about structure of a relational database, we use term table to visualize
basic stone of database. It is mathematically incorrect term, in theory we use term relation.
Now we will go through other basic terms of relational database, which will be shown on
an example. We want to make a database of city citizens, where we want to know their
name, surname, address and date of birth, further we assume, that each person has unique
birth number. Each of these characteristics is called attribute. Each attribute can get one
of different values (for address it would be one of city’s streets). Complete set of these
values that attribute can have is called a domain. Information that characterizes one of
citizens, puts in relation different values of attributes from various domains. Such a group of
attributes belonging together is called a n-tuple. Here is a complete mathematical definition
of what has just been explained.
Given a collection of sets D1 , D2 , ..., Dn (not necessarily distinct), R is a relation on
these n sets if it is a set of orderes n-tuples < d1 , d2 , ..., dn > such that d1 belongs to D1 , d2
belongs to D2 , ..., dn belongs to Dn . Sets D1 , D2 , ..., Dn are the domains of R, The value n
is degree of R.[1]
In writen text we write simply R(A1 , A2 , ..., An ) if we want to describe a relation R with
attributes A1 ...An .
6
Figure 2.1: Relational database1
2.1.4
Constrains
Each database usually contains more than one table and information in these tables can
relate to each other. For example we already have table of our citizens and now we also
have table with city houses. Each house has different size, different status and different
owner. And here we get to a relation between our two tables. House owner is always a
citizen. So there is relationship owns“ between those tables. In relational database this
”
relation is purely logical, not physical (pointers) as before in pre-relational model, and it
is created upon equality of values in certain rows of both tables. In the example it will be
owner and name. To make it possible to create such relations, we need to make sure that
each row will have unique way how to identify itself and then there must exist a link to
this identifier in second table. In relational databases this is achieved by using keys. For
identification it is a primary key and for links it is a foreign key. Data in every database
is always somehow constrained. There are two types of constrains, general and specific.
General constrains depend on usage of database and data is constrained in way of data
type or minimum/maximum possible value. On the other hand, general constrains are the
same for every database and they have effect on key attributes.
Candidate and Primary Key
Primary key is used to identify each row of a table, therefore it must be unique. We usually
use logins, birth numbers or just integers as IDs for primary keys. Sometimes there can
be more candidates for primary key, so we have to chose one of these candidate keys to be
primary. Attribute CK of relation R is called a candidate key if applies to these rules:
• Values of attribute CK in relation R are unique - there are no two n-tuples in relation
with the value of this attribute.
• Attribute CK is specific and minimal - it is not composed of more other attributes
and can not be divided into simpler
These rules must be valid in any time given. Primary key is then one of candidate keys, the
rest of them are called alternative keys or secondary keys. We usually chose the simplest
candidate key to become primary. Primary keys are used in other tables as links to table
1
https://en.wikipedia.org/wiki/Relational database
7
containing primary key as attribute, therefore not only that it has to be unique, but it also
can not be unset or unknown, in terms of SQL we call such a value NULL, so primary key
can never be NULL.
Foreign Key
Attribute FK of relation R is called foreign key, if applies to these rules:
• Each value of FK is fully inserted or fully not inserted
• There is relation R2 with candidate key CK, that any value of FK equals to some of
values from CK of n-tuple from that relation.
Again we can draw some conclusions. We see that foreign keys do not have to have a
value, that might be case where for example some house is not owned by anybody, so the
attribute owner will be empty. It is important that every foreign key really leads to some
candidate key in other table, because that is the thing keeping database consistent and it
is responsibility of administrator/programmer to secure it.
2.2
Tree Databases
These databases, also knows as hierarchical, are databases, which were mainly used at the
beginning of computer era, before times when the relational model became most common
standard. As the name suggest, data in this model is stored in tree structures. From
different point of view a tree allows us to store data in child-parent structure, which is
referred also as 1-n structure, because each entry can have only one parent, whereas a
parent can have multiple or no children. In this type of database, entries are connected by
these parent-child relations, which are in fact simple pointers.
To look at a hierarchical database in the same way as at relational one, table would be
entity type, row a record and at last, column would be an attribute. These databases are
not much used nowadays and if, then just for special models like geographic informational
systems or file system data. Most used implementations of hierarchical databases in the
present are Windows Registry developed by Microsoft and IBM’s IMS.
2.2.1
XML Databases
According to [12], XML database is another type of database model, this one is specific by
storing data in XML format. This data can be queried as in other models, but can be also
exported and serialized into other formats. We divide XML databases into three major
groups:
• Native XML Database (NXD) - the basic unit of this database is an XML document; it
does not require any underlying physical model as it can stand on a relational, object
oriented or any other kind of database or even just on indexed or compressed files; it
defines XML document logical model, that at least must have elements, attributes,
document order and PCDATA2 .
2
Parsed Character Data
8
• XML Enabled Database (XEDB) - this kind of database has also a XML mapping
layer, that manages the retrieval and storage of XML data. Mapped data is stored
in a specific format, so the original XML meta-data can be lost. To manipulate this
data we can use either special XML technologies as DOM, SQL3 or XPath4 .
• Hybrid XML Database (HXD) - This kind of database can be treated as both NXD
or XEDB, it is just on application which way it will prefer. Implementation of HXD
is for example Ozone.
XML databases find their place with informational portals, product catalogues, business to
business document exchange and many others. When applying XML databases for these
solutions, they offer far bigger performance then relational databases and they are more
convenient and easier to use, manage and expand.
XML
XML stands for Extensible Markup Language, which is nowadays format, that many applications use for encoding their documents. It was created to be both human-readable and
machine-readable. Fundamental unit of XML document is an element, which is created
using tags, a text construction that begins with <“ and end with >“, for example:
”
”
<person>bambusekd</person>
would be element representing a person bambusekd. Each element can have attributes,
those can be either created inside beginning tag or as a separate couple of tags.
<person age=‘‘21’’ position=‘‘student’’>bambusekd </person>
or
<person>
<name>bambusekd</name>
<age>21</age>
<position>student</position>
</person>
both examples provide the same information.
XML was designed to be simple and to have wide scale of usability on the Internet. It is
data format base on Unicode, so it can serve in any of world’s languages. No matter the fact
XML was designed for documents it found place also in many web services as representation
of arbitrary data structures. XML is used in all major office tool applications as Microsoft
office, OpenOffice, LibreOffice etc. XML has also been father to many other formats, that
use XML syntax as XHTML 5 , RSS6 and others.
3
Documental Object Model,Structured Query Language
http://www.w3schools.com/xpath/
5
http://www.w3schools.com/html/html xhtml.asp
6
http://www.w3schools.com/rss/rss intro.asp
4
9
2.3
2.3.1
Other Databases
NoSQL
Term NoSQL was first used in 1998 by Carlo Strozzi, who described his lightweight relational
database as NoSQL [10], because it did not follow design, structure and rules of typical
SQL database. From then, you could not hear much about NoSQL, until a boom of social
networks and a need for storaging huge amount of simple data came in 2009. In this year
a guy from Last.fm7 made a statement, that NoSQL databases are those, that do not care
about atomicity and consistency as traditional relational databases.
Main goal of NoSQL database is to provide lighter database, that would be faster and
with higher availability, this is achieved by a model with looser consistency. That allows
faster horizontal scaling. These databases consist of key-value entries, where relationships between them are not that necessary. NoSQL is focused mainly on adding data to
database and retrieving them, not more. This with omission of relations allows these kind
of databases to be used just for certain types of models. Such models can be millions of
posts on social network like Facebook or Twitter, where there is no need of relations in
between data, we just need to store them and retrieve them.
Term NoSQL does not mean that these databases are not SQL databases, because in
fact some of them allow SQL-like queries above them, it rather means not only SQL“.
”
Work on language that would be specifically made to query NoSQL database has began
in 2011. This language is called UnSQL (Unstructured Query Language) and it can query
collections of documents, what in relational model would be tables and rows. Unfortunately
UnSQL is not capable as SQL in manners of data definition, so there is no parallel query
to SQL’s CREATE TABLE or others in it.
Document Store Databases
Basic building stone of these databases, as name already says, is a document. As in relational model there are tables, here there are documents. Each implementation treats
term document differently, but all of them encode data using one of formats as is JSON,
XML, YAML or PDF. In comparison to relational model, records here do not have to follow
strict scheme of data structure, that means that one type of entry can have on a different
occasions different sets of attributes. This allows to add any new information at any time
without any problems with predefined data structure.
To address a document we use a unique identifier that can be either name or URI.
Usually these values are hashed to indexes, so data retrieval of any document is very fast.
Basic query needed with this database is to retrieve document base on its identifier, however some implementations allow us to retrieve documents based on their content, but this
depends on each implementation.
JSON8 - JavaScript Object Notation is a standard made to represent data structures and
associative arrays. Although it is derived from JavaScript, which is a scripting language
used mainly in web environment, it is language-independent. JSON standard can be found
in RFC 4627, it was first introduced in 2001 by Douglas Crockford and it is nowadays very
popular serialization format used in server-client communication next to XML and others.
It contains just few basis data types: number, string, boolean, array, object and null. The
7
8
Free internet radio catalogue
http://www.json.org/
10
format was created in human readable form. Compared to XML it has lower demands on
data processing. Example of a person data encoded in JSON looks like this:
{
"firstName":"David",
"lastName":"Bambusek",
"job": {
"occupation":"student",
"year":"3"
},
"age":"21"
}
YAML9 - is a recursive acronym for YAML Ain’t Markup Language“, previously Yet
”
”
another Markup Language“. It was brought on the light of the computer world in 2001 by
Clark Evans and it is another data serialization format, that is based on combined basis
of programming languages as Python, Perl or C, XML and format of electronic mail. It is
again representant of human-readable formats as was JSON or XML. YAML’s main goal is
to offer a way how to map high-level languages data types as are lists, scalars or associative
arrays, to be easily modified, or viewed, so the output could be used for configuration files
or document headers. Thanks to its syntax with white-space delimiters it is very easy to
work with YAML using grep or some of scripting languages as Perl. Same example used in
JSON paragraph would look this way in YAML:
first_name: David
surname:
Bambusek
job:
occupation: student
year:
3
age:
21
Graph Databases
Graph databases have completely different structure than relational databases as can be
deduced from article [9]. They consist of nodes/vertices, edges/relationships and properties/attributes. Graph database is index-free, this is due to fact that every entry has a direct
pointer to his neighboring element, so no lookups are needed. So as relational databases are
based on mathematical theory of relations, graph databases are build upon a graph theory.
Graph theory is useful in many ways, graph algorithms are used to find shortest paths,
measure statistics like PageRank, closeness and it also offers a basis for high-performance
databases.
In graph a node represent an entry, that means person, company etc. Property is an
information, that describes, details or specifies a node. If there is node David Bambusek,
then one of properties could be student“. Then we have last item of graph - edge, which
”
connects nodes with other nodes or nodes with properties, so in fact it represents the
relationship between the two items they connect. These edges are the most important
thing in graph model and carry the biggest amount of information. The way how to get
9
http://www.yaml.org/
11
Figure 2.2: Graph database10
some worthwhile information is to examine connections and properties of nodes we are
interested in or of those we are led to on a way from starting nodes. In comparison to
relational databases, graph databases are faster with smaller amounts of data as they do
not need to perform join operations. It is better to use them in case, where it is known
the database will change, grow and in some kind evolve, meaning we will add new kinds
of nodes or add new information to existing ones. On the other hand, when we compare
performance of relational and graph database on the same set of large data, relational wins.
2.3.2
Object Oriented Databases
Object oriented databases as described in [14] differ from all other types of databases in
their attitude of storing data. In other databases, data is stored using basic data types
as integers and strings. In this database model data is stored in objects. Same thinking
is used in OOP languages as C++ or Java. Objects were made so we could better reflect
real world objects. Each object is compound of two basic parts. First is set of attributes,
attribute is object’s characteristic , attribute can be either simple data type as integer or
it can be again object. Second part is collection of methods, these define object behavior.
All together object contains data and also executable code. Creation of new object is
called instantiation. In this model, there exist so called classes, which are in fact templates
for objects, they define their attributes and methods, but they do not contain data by
themselves. To identify objects an OID in used in this model, which is unique ID of each
object.
There are few fundamentals of object oriented approach, that are valid also in databases.
10
http://en.wikipedia.org/wiki/Graph database
12
First thing is that objects communicate in between themselves using messages, depending
on received message object does something that is defined by its behavior. Next thing
is encapsulation, that means that inner object’s implementation is not visible for other
objects, they can only see the interface. Therefore object itself or rather object data can
be changed just by its own methods. This is so that there is no possible way how to make
incorrect change to data stored in object. Also inheritance is very important, in fact it is
one of the most useful features of OOP attitude. It is a way how to make relationships
between objects and how to add some more specifications to new objects based on already
created ones.
We should use object databases in cases when we have very complex data with a lot
of many-to-many relationships. There is no sense in using them for small databases with
simple relationships. Object database advantages over relational are that thanks to inheritance, we do not need that much code, the data model reflects the real world by using
objects, navigation is much easier, there is reduced paging and finally it works very well
with distributed architectures. On the other hand, relational model with tables is simpler,
it is more efficient with simple data and there is generally bigger support, more software
and more standards for relational databases, it is likely to say that object oriented approach
is still bit wilder then more stable and standardized relational.
13
Chapter 3
Directory Services
Complete description of directory services is mentioned in articles written by ITU-T 1
organization [7] [8]. Directory services allow us to access data of directory type. By term
directory we mean specialized database of telephone numbers, names, email addresses and
others. These databases have their ancestors in printed directories of telephone numbers
used by millions people around the globe. When computers came on scene during 1980’s,
also new network services using the Internet to create global telephone number directory
showed up. These directories were base on ITU-T X.500 standards and later in 1990’s, new
standard was introduced, it was IETF Lightweight Directory Access Protocol (LDAP),
which completely replaced X.500.
LDAP architecture, which is based upon X.500 architecture was created in 1997 and
has had many actualizations. Today the most actual recommendations for LDAP are RFC
4510 and RFC 4511. Main goal for LDAP was to create a distributed directory service,
that would treat all user equally and that would be easily extended. Basically for the same
reason X.500 was created, but due too difficulty of implementation was never so successful
as LDAP.
Architecture
X.500 defines directory as a set of opened systems, cooperating in intention of preserving
”
logical database of information containing set of object from the real world“ [7]. The
architecture of database is hierarchical and is called Directory Information Base (DIB). It
consists of entries, where each of them has set of information about itself, called attributes.
Each attribute has a data type and a value. Each entry corresponds to some class of object
and according to that class has different attributes, in other words object class defines
structure of each entry.
We can imagine DIB as a tree, that is organized from top to bottom, where the most
top entry represents the most generalized entry, for example country, going down the tree,
we meet regions, then companies and so on. Each entry needs to be identified somehow,
for this we use distinguished name (DN). It always consists of DN of its superior entry DN
and its own DN.
Main difference between directory and relational database is in what we expect from
them. Directories usually hold stable data, that are supposed to be read many times, rather
then modified. We usually work with just one entry, so there is no need for operations like
join or complicated search functions over more than one entry. Directory can contain
1
International Telecommunication Union - telecommunications sector
14
duplicated data if it helps the performance of it. Most applications that use directories
expect quick response from them.
Data stored in DIT can be physically stored on one server or can be distributed on more
servers, it is wise to store them on more servers in case that we want to avoid overload of
one server due to too many requests, we can also make a replication of some part of DIT,
so request on this part can be divided onto more servers.
X.500 Directory
This standard is ancestor and template for all later created directory services. It was
created in 1988 and it is environmentally and architecturally independent. Its concept is
quite similar to DNS, where it consists of entries representing all countries of the world.
X.500 uses many protocols:
• Directory Access Protocol (DAP) - to access database of directory service
• Directory System Protocol (DSP) - to exchange information
• Directory Information Shadowing Protocol (DISP) - for data sharing between servers
But X.500 was too difficult to implement, therefore a lightweight version called LDAP was
created. It is much faster, effective and uses just one protocol called also LDAP.
3.1
LDAP
Lightweight Directory Access Protocol (LDAP), described in [13] represents not only internet protocol for directory access, but entire directory service. LDAP is based on ITU-T
X.500 standard and is described by four so called models. Each of them describes one
different view on the directory service:
• Name model - describes directory structure made of entries, that are identified by
distinguished names (DN).
• Informational model - describes information which all together form so called directory
scheme, those are data types, operations that can be done upon them and information
how to store them. It also describes entries, attributes and their possible values.
• Functional model - describes operation done by LDAP protocol, where the most used
operation is search and this model specifies where to search, using what keys and so
on.
• Security model - describes how data is secured in database, that means if there is
some authentication, encryption and access rights.
3.1.1
Name Model
Name model describes organization of data and relationships between them. Name model
describes how entries are stored into tree structure called Directory Information Tree (DIT).
In this tree, each peak of the tree is entry, that can have ancestor/parent and descendant/child, to which they are connected by an edge. The structure of the tree corresponds
to company structure, geographical structure or any other hierarchical structure, that usually reflects some real existing model. At the most top, there is a special root entry. To
15
identify an entry we use distinguished name (DN), which is made from of all DNs of entry’s
parents. There is also special type of entry called alias, which refers to some other entry.
3.1.2
Informational Model
Informational model [15] describes structure of entries that create DIT (Directory information tree). Each entry contains information about itself, this information is stored using
attributes, entry can have more attributes. Each attribute has a data type and a value,
that can be either compounded value or just a simple value. Entry’s main identification
is its DN (Distinguished Name), which is created by combining nodes’s name and DNs of
nodes, that are situated on virtual route in the tree structure from actual node to tree’s
root node.
Lets make an example of Red Hat employee David Bambusek, entry will have an attribute cn, that goes for common name and mail, that stands for e-mail address, so in the
directory there would be entry:
dn: cn=David Bambusek, dn=redhat, dn=com
cn: David Bambusek
mail: xbambu02 [at] stud.fit.vutbr.cz
Each entry belongs to a certain type of object class, these classes can be edited and
created by database administrator. Object class is a set of objects, that share the same
”
characteristic.“[8] Basic properties of class are that it defines which attributes entry derived
from that class must and may have, defines which objects and entries belong to them,
takes care about placement in DIT and checks operations being done over entries. As it
is common in OO (Object oriented) attitude, classes can inherit some features of their
parents. In LDAP we have 3 main types of classes:
• Abstract class- no entry can be based on this class, they only serve as templates for
other classes.
• Structural class - each entry must be made based on at least one of these classes,
every structural class is based (directly or indirectly) on the highest abstract class
top.
• Auxiliary class - used to extend attributes of entries.
Formal definition of class according to ABNF(Augmented Backus–Naur Form) looks like
this:
ObjectClassDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
16
The only must parameter as we see is OID - which is object identificator. Object class of
our Red Hat employee from example would look like this:
(2.5.6.6 NAME ’employee’
SUP top
STRUCTURAL
MUST ( cn \$ mail )
MAY ( departement \$ telephone ) )
That means there must be always employee’s full name and mail given and we can optionally
add department where she/he works and her/his telephone. We have two different types
of attributes, they can be either user attributes, which are already presented cn, mail
and others, these can be changed or modified, then there are operational attributes, that
are generated automatically, are permanent and are used for administration, for example
information of who created entry and when. Each attribute is identified by unique Object
Identifier (OID). Basic types of classes and attributes can be found in RFC 4519.
3.1.3
Functional Model
Functional model describes operations that can be done upon a directory, that means
adding, modifying, deleting entries and querying them. Not only that it describes these
operations, but it also defines way and scale of a query/search operation. If we have a big
directory, it can be very useful to limit our query just on some part of directory. LDAP
defines three types of search.
• base - search is done just in set base object
• one-level - search is done just in direct child of base object
• subtree - search is done in whole subtree of base object, with that object included
For a search operation we can use different filters and comparing rules. Not all data types
support all kinds of comparing. For example operations like greater than/less than can be
used only on attributes that can be ordered alphabetically/numerically/. . . Basic filtering
rules are mentioned in a table 3.1.
Rule
equality
substring
approximate
greater than
less than
presence
AND
OR
NOT
Format
(attr=value)
(attr=[leading]*[any]*[trailing])
(attr =value)
(attr>=value)
(attr <=value)
(attr=*)
(&(rule1)(rule2))
(|(rule1)(rule2))
(!(rule1)(rule2))
Table 3.1: filtering rules for LDAP
17
There are few basic operations in LDAP that should be mentioned.
• Bind - is used to establish a connection between server and client, to agree on type
of authentication and to login into directory
• Unbind - is used to end the connection
• Search - basic search operation, you must define the base object of search, the scope,
the filtering rule, list of attributes we are interested in and maximal number of results
we want to get
• Compare - is used to compare attribute values of set entries
• Modify - is used to change defined entry
• Add - is used to create new entry
• Delete - is used to delete an entry
• Abandon - cancels previous operation
3.1.4
Security Model
Security model provides protection to data in directory against non authorized access. All
LDAP servers have SASL authentication implemented. We can divide LDAP servers into
three categories:
• public servers with read-only data with anonymous acces
• server supporting password authentication, MD5 SASL implementation is needed
• server supporting cryptation and authentication, they must implement TLS operations and authentication with public keys
3.1.5
LDIF
The LDAP Data Interchange Format2 (LDIF) is a standard, described in RFC 2849, that
defines a plain text format for representing data stored in LDAP directories and LDAP
operations. From LDIF point of view, LDAP directory is a set of entries, where each of
them has its own record.
Its birthplace was University of Michigan, where it was created by Tim Howes, Mark C.
Smith and Gordon Good. LDIF has been extended and updated few times creating current
standard specified in RFC 2849. We have already mentioned an example of LDAP entry, so
here we have a modifying request on an entry, that adds e-mail address to an existing entry:
dn: cn=David Bambusek, dn=redhat, dn=com
changetype: modify
add: mail\newline
mail: xbambu02 [at] stud.fit.vutbr.cz
2
RFC 2489
18
3.1.6
LDAP Usage
Directories are computer version of old telephone directories, so they most usually consist
of information about people/organization/services, so the main usage is to get some contact
information.
This is used for example with e-mail clients. When writing email, you insert name of
recipient, mail client will ask LDAP server for his email address and that server will answer
by exact address or in case there are more people with same name with all their addresses.
Quite similar situation is when using VoIP communication, each VoIP telephone has
LDAP client, that can ask a LDAP server for a telephone number of a given person. Next
example of LDAP usage is verification of users trying to access some services, most usually
web service. Web client will ask user for login and password, send it to server, which will
try to bind to LDAP server, which contains approved user logins and passwords, with this
data and in case bind is successful, user is authorized. This approach is also used in Unix,
where instead to authentication using /etc/passwd LDAP server is used.
3.1.7
LDAP Implemantations
There are many implementations of LDAP servers, some of them are open source, some of
them are commercial. Here is a list of the most known of them:
• 389 Directory server (Fedora Direcory Server) -it was developed by Red Hat. The
name comes from the port number for LDAP, which is 389. This implementation is
built in Fedora and is supported by many other distributions like Debian or Solaris.
• Active Directory - Microsoft’s implementation of a directory service, it was created
in 1999 as part of Windows NT Server, it not only uses LDAP, but also Kerberos and
DNS.
• Apache Directory - is an implementation of directory service entirely written in Java,
it is an open source project created by Apache Software Foundation
• FreeIPA - is in fact combination of already existing projects, that provides managed
Identity, Policy and Audit (IPA), it is focused on Unix computer networks. It uses
Kerberos 5 for authentication Apache and Python for Web UI and 389 Directory
server for LDAP. There is possibility to cooperate with Microsoft’s Active Directory
using Samba.
3.2
LDB
LDB is a LDAP-like embedded database used in Samba project. information about it can
be gathered from [11]. Although it provides LDAP-like API, it is not LDAP standard
compliant, its highest priority is to be compliant to Active Directory. LDB can be seen as
a solution providing something between key-value pair database and an LDAP database.
LDB is basically a module above TDB that manipulates key-value data into LDAP-like
structure.
LDB is a transactional, that means it checks if any error occurred during changing the
database data before committing it and if so, all the changes are backed, so the database
is in the same state as before intended change. It is also modular, that allows any new
19
functionality to be added or removed according to our needs on database performance.
Available backends uses TDB, LDAP or SQLITE3.
LDB has many advantages of LDAP like custom indexes, it offers powerful search options, it is hierarchical and its structures can be easily modified or extended. On the other
hand it keeps also some advantages of TDB as is fast search, all the data is stored in one
file and it is easy to backup.
LDB enables fast searches thanks to function, that takes care of building indexes for it,
when a new index is added, whole database is scanned so the indexes can be automatically
rebuilt. Also there is no need for a schema, since any object can store arbitrary attributevalue pairs.
LDB has many powerful tools. In between them is worth mentioning ldbsearch and
ldbmodify.
ldbsearch - its syntax is very similar to ldapsearch in LDAP, by using -H option, you
define backend which should be used (tdb,sql, ldap,. . .) and then as in ldapsearch comes
definition of the search scope, ehw base dn and a LDAP-like search expression.
ldbmodify - is a tool using known LDIF format, it allows you to explore and change a
snapshot of the directory in a text editor, you can use filters to show just object you want
to see, it can be also used to backup and restore database and it works against an LDAP
server too.
3.2.1
TDB & DBM
TDB is a successor of DBM database, made by Samba team, very nicely described in [11]. Its
main difference from DBM is that it allows multiple writers to use database simultaneously
and uses internal locking to avoid one entry to be rewritten by one user, while another one
is working with it. DBM is a very simple database allowing to store any data in simple
key-value structure. It was designed by Ken Thompson from AT&T in 1979. Each key is
hashed to allow fast data retrieval. DBM uses fixed-sized buckets for primary keys, that
split as database grows. Hash is usually directly connected to physical disk, so the retrieval
can be very fast, because there is no need for any connecting or difficult querying.
20
Chapter 4
SSSD
4.1
User Login in Linux
In order to work with a Linux system, one must first log in. Presentation [5] concerns this
topic in very detailed way. No matter if there is some GUI available or you log in using
command line, you always have to enter your name and password. Term password covers
not only ordinary text password, but it can be also fingerprint or any other device similar
to it. Logging in has two phases. As first system needs to get information about user such
as what her/his home folder is and as second, it is neccesary to authorize the user.
4.1.1
Identification
Information about users or for example hosts can be usually found in various files like
etc/passwd or etc/hosts. Problem is that they are not on the same place, therefore some
API is needed to work with all of them. In Linux, there is NSS (Name service switch) that
serves this purpose. It is part of a standard C library, so it can be run on any system. It is
a modular feature, where each module works with one source managing one type of object.
For example one module will work with user from LDAP and second with passwords from
etc/passwd. NSS is configurated using its config file in etc/nsswitch.conf.
4.1.2
Authentication
For authentication there is another API called PAM (Pluggable authentication module). It
provides four main features - account, auth, seesion and password, where auth is the most
important for us, because it tells us whether user can authenticate. PAM has also many
modules, some of them are even based on anothers and complete programming is quite
complicated. Most used modules are those providing connection to etc/shadow, LDAP,
Kerberos, some additional modules offer advanced functionality as password quality checks.
4.1.3
Problems Using NSS and PAM
Using NSS and PAM is possible for loggng into some system and this solution is working
quite well, but there are few problems connected with it. For example when a situation of
identity overlap occurs, when we have two domains with the same user, we have to somehow
decide who is who and how he will be identified. Second big problem is how to query a
remote server if a computer is currently offline. There are some options to solve this - a
replica of LDAP tree can be made locally, information can be saved into etc/passwd or
21
whole directory can be stored in cache, but all of these solutions are unhandy. Also with
usage of NSS and PAM comes a lot of work with configurations for administrators, that
are usually not very happy when given such a big amount of work.
4.1.4
SELinux
Security-Enhanced Linux (SELinux) is an implementation of a MAC (Mandatory access
control) mechanism in the Linux kernel, that does check for allowed operations after standard DAC(Discretionary access controls) checks are done [2]. This feature is added to
many Linux distributions by default (RHEL, Fedora). It was originally created at the
Utah university by Flux team with support of US Department of Defense and it was called
FLASK(Flux Advanced Security Kernel). It was later enhanced by the NSA (National
Security Agency) and released as open source software.
Normally each user has a right to operate with his own files as they want to. There is
no relevance to user role, function of program or about sensitivity of the data, therefore it
is very hard to create a system-wide security policy. SELinux adds labels to all objects e.g.
files, processes and users, this label define SELinux context. This context provides user
identification, his role, type and level. This information is used to decided whether user
will be granted access or operation will be permitted. SELinux default policy is what is
”
not permitted, is forbidden“ known as least privilege principle, which serves as protection
against any system malfunctions and therefore highers the security level.
4.2
Basic Function
SSSD is a set of daemons providing an option to access various identity and authentication
resources through one simple application, that also offers offline caching [4]. SSSD was
created to solve all the problems mentioned above. For further information study of [3] is
highly recommended. Main idea of SSSD is to provide enhancements to Fedora or any other
Linux distribution, that supports SSSD. First thing that SSSD offers is offline caching for
network credentials. This is a big ease if you use a centrally managed laptops, because all
the services as LDAP, NIS or FreeIPA will in fact work also offline. So what SSSD in fact
does is that it provides access to SSSD cache for local services, cache stores information
about identities from various providers as LDAP, Active Directory or Identity Management
domain. SSSD used to be a client side part of freeIPA, but lately became separate project.
Next feature of SSSD is fact, that it reduces the overhead of opening new sockets for
each query on LDAP, by using just one persistent connection to one or more LDAP/NIS
servers, each acting as separate namespace. The only service that communicates with
LDAP is SSSD Data Provider and that reduces the load on LDAP server to one connection
per client. SSSD can be connected to various domains-sources of identities, where each of
them can be connected with more servers, so when one of them is down, next server on list
will be used.
Additional innovation, that SSSD brings is a service called InfoPipe, that works on
D-BUS system. This service contains extended data information as preferred language or
your profile image, which until now was mainly concern of various configuration files in
user’s home directory, which is not always available, due to mounting of home directory
has not yet been done.
In summary, the benefits of SSSD are that laptop users can use their network logons
even when they are offline, with SSSD you only need to manage one account. Just one
22
service is needed to work with multiple identity and authentication providers. Developers
will have access to InfoPipe, what brings new approach for extended user information,
other services as FreeIPA, LDAP or NIS can take advantage of offline features thanks to
the caching and the last, that it will provide FreeIPA client side software, for entering into
FreeIPA domains. And the whole configuration of SSSD is matter of few lines compared to
NSS and PAM together, so it is very easy to use for administrators.
4.3
Architecture
Figure 4.1: SSSD architecture [5]
4.3.1
Processes
The SSSD is a set of four main processes, each of them has its own special function:
1. the monitor - the process, which checks if other processes are running, it spawns them
on the start and then re-spawns them if one of the periodical check shows that any
service is not working.
2. a data provider - this process is responsible for communicating with various backends
and populates cache with data obtained from them. For each remote server, there is
one data provider process.
3. responders - are processes, that communicate with system libraries as NSS or PAM
and try to give them data, that they are asking for, from cache. In case that data
in cache is expired or is not there at all, it gives a signal to data provider to obtain
it. When data is obtained, it is stored in cache, responder is informed about it, so it
again goes into cache and gets the needed data.
4. helper process - there are some operations, that could be blocking, therefore SSSD
performs them in special sub-processes, that are forked from the Data Provider.
23
4.3.2
Communication
D-Bus
For communication in between processes the D-Bus protocol is used in SSSD. Communication is done in form of sending messages. D-Bus can be divided into four primary
components:
1. The D-Bus Server - is used for establishing connections. It can be identified by its
address, that consists of a transport name, colon and an optional list of keys and
values separated by commas.
2. The D-Bus Connection - these connections are peer-to-peer connections, so one end
listens for method calls, and the other one of them initiates methods and vice versa.
3. The D-Bus Message - There are two types of messages:
• one way messages - these are D-Bus Signals and D-Bus Errors, they usually carry
a simple message from one end of connection to the other one. These are most
often signals to stop/start service or to notify that some error has occurred.
• answer messages - these are D-Bus Methods, their functions is to run a method
on a remote process as it would be run locally, after calling the method, there
can, but not necessarily has to, be an answer to it that goes back to end that
called the method.
4. The D-Bus System Bus - is not used in SSSD, but it is part of D-Bus protocol. It
was designed by the Freedesktop project and was created to handle multiple communication between system daemons.
S-Bus
To ensure that SSSD will have good performance, it works completely in non-blocking way
with help of the tevent1 event loop library developed as part of the Samba project. To
provide certain level of abstraction and in order to make possible to integrate D-Bus with
the tevent, SSSD uses S-Bus - a wrapper created around D-Bus library.
Two processes in SSSD work as S-Bus servers, which is an abstraction of D-Bus server,
they are identified by a UNIX socket, mentioned in the heading text, and they are:
• The monitor - it can call methods as ping“ to check processes as was described above
”
or rotateLogs“ to rotate logs by force and others.
”
Socket - /var/lib/sss/pipes/private/sbus-monitor
• The Data Provider - it calls different methods depending on the data type that is
requested, for example the NSS can call method getAccountInfo“.
”
Socket - /var/lib/sss/pipes/private/sbus-dp $ domain name
1
http://tevent.samba.org/
24
Chapter 5
SSSD Database
SSSD database stores few different kinds of objects. There are 7 of them in total and in
this chapter we will briefly introduce each of them. As was previously said, each object is
an instance of a class that defines object’s attributes. Attributes of objects like users and
groups are very similar to those typically used in LDAP, so we can find a lot of similarity
here. Complete list of attributes for these objects of LDAP character can be found in
ldap opts.h1 .
5.1
Users
User objects store basic information about users, so in fact a user object is a virtual identity
of a real person. Every user can be member of multiple groups or netgroups.
objectClass=user
attribute
uid
userPassword
uidNumber
gidNumber
homeDirectory
loginShell
gecos
description
user name
user password
unique identification number
group identification number
home directory
user shell
full name
Table 5.1: User attributes
1
sssd-1.9.91/src/providers/ldap/ldap opts.h
25
5.2
Groups
Users can be members of groups, groups can also belong into groups, so multiple nesting is
possible. There is a tool sss groupshow that can be used to display group members.
objectClass=group
attribute
cn
userPassword
gidNumber
description
group name
group password
group identification number
Table 5.2: Group attributes
5.3
Netgroups
Netgroups are slightly different from groups, there are network-wide groups, that define set
of users that have access to specific machines, set of machines with specific file system access
and set of users with administrator privileges in specific domains. Netgroup is specified by
a name and its members are in format of triples where one field is for machine, second for
user and third for domain name.
objectClass=netgroup
attribute
cn
nsUniqueId
description
netgroup name
netgroup unique UID
Table 5.3: Netgroup attributes
5.4
Services
There is not much to say about definition of service, as the name speaks for itself, each has
a name and runs on a different port.
objectClass=service
attribute
cn
ipServicePort
ipServiceProtocol
description
service name
service port
service protocol
Table 5.4: Service attributes
26
5.5
Autofsm Maps
[3]Autofsm map is a special feature used by automounter to automatically mount filesystems in response to access operations by user programs. When automounter is notified
about attempts to access files or directories under selectively monitored subdirectory trees,
it dynamically and transparently accesses local or remote devices.
objectClass=automountMap
attribute
cn
automountInformation
description
autofs entry key
autofs entry value
Table 5.5: Autofs map attributes
5.6
Sudo Rules
[3]Sudo rules define users who have been granted some kind of access, commands that are
in scope of this rule and a hosts that this rules applies to. They can also contain some
additional information, but it is mainly only who can do what and where“.
”
objectClass=sudoRule
attribute
cn
sudoCommand
sudoHost
sudoUser
sudoOption
sudoRunAsUser
sudoRunAsGroup
description
sudo rule name
command
host
user
option
run as certain user
run as certain group
Table 5.6: Sudo rule attributes
27
5.7
SSH Hosts
[3]SSH is a cryptographic network protocol for secure data communication, that allows us
to connect to remote machines. SSH hosts are then those machines we connect to. To
connect to a host we need a key, which is exactly what we store in the database.
objectClass=sshHost
attribute
cn
sshPublicKey
sshKnownHostExpire
description
ssh host name
public key
time until entry expirates
Table 5.7: SSH host attributes
28
Chapter 6
Querying Tool
6.1
Program Specification
Querying tool is a console application called sss query, its purpose is to query all kinds of
data, that are stored in SSSD database and offer its users results of these queries. Application will be a part of a tool package for administrating SSSD database. User can chose
how wide a query will be, chose whether to search just in one particular domain or in all of
those, which are available. It is possible to search for one exact entry, based on its unique
identification, which varies depending on a type of an entry we are searching for or can
provide information about all entries of the same type eg. users, groups etc. currently
present in the database. For each entry type, there is a default set of attributes, that will
be printed out, but if user wants to see just some of the attributes, he is free to notify the
tool by adding them as an optional flag and application will provide just these to him.
Implementation language of the application is C.
6.2
Basic Information and User Interface
Application is able to answer queries on these types of objects:
• users
• groups
• netgroups
• services
• autofsm maps
• ssh hosts
• sudo rules
• domains
• subdomains
29
For each item there is a predefined set of attributes, that will be printed out, in case one
does not insert her/his own attributes as an optional parameter. Table E.1 shows default
attributes for each entry type. Application has two mandatory (E.2) flags and one optional
(E.3) flag.
The application is a standard console application with no graphical user interface, all
the communication between user and the tool is done upon the insertion of application’s
parameters and flags at the time of executing it. Result or multiple results if so, are
displayed on standard output in plain text format, if there is no result or some problem
occurred during run of the application an error message will be displayed. After completion
of query, successful or not, an application is terminated, therefore if more queries are
requested, we need to run the application once again for each query.
To use the tool, run application as following :
$# ./sss_query <object_type> <identification> <attributes_to output>
A complete list of flags used to operate the tool is listed in appendix E. An example of
communication between user and application looks like this:
Query on existing object
$# ./sss_query -u -N bambusekd -S uidNumber,name
$ === Showing requested user ===
UID Number(uidNumber): 00015487
Name(name): David Bambusek
Query on non existing object
$# ./sss_query -u I name=filutam
$ Object not found!
Application error
$# ./sss_query -s I gid=002587
$ You can use GID just for identifying groups!
30
6.3
Application Architecture
Until now, there has been no actual way, how to find out any information about objects
stored in SSSD database easily. That caused many problems when administrators using
SSSD communicated with SSSD developers trying to solve problems that occurred during its
usage, because administrators were unable to specify what objects are in their databases or
they were unable to gather information about database itself, its domains and subdomains.
Another problem is fact, that SSSD is very wide project with a lot of source code and many
modules, providing each different functionality and working with different objects. There
is no centralized file, that would describe all the objects SSSD works with, what certainly
does not ease work for developers or users.
Therefore a tool, which would be able to offer all the functionality that has been missing
and complete enumeration of objects and their attributes was needed. The main goal was
to use as much functionality already implemented in SSSD as possible, to make the tool
easy to use and make it fast. At the same time to be compatible with existing parts of
SSSD and to be made general enough to be potentially expandable in future as SSSD will
evolve and change.
Main challenge of this project was to get familiar with a large number of techniques
and technologies used in SSSD, to fully understand their function and to learn how to
use them in order to gather all the knowledge needed to design a tool, which would be
functional and compatible with the rest of SSSD. Since there is no documentation available,
the only way how to study SSSD architecture and function was to explore vast source
code and many dependent libraries to deduce how things work. The biggest task was to
find already implemented functions from other modules, where they are used for other
purposes, that could be re-used for the tool. As many people work on SSSD and each
person creates different part, where functions querying database objects are used just as
auxiliary functions, there was no common knowledge of them, so it was necessary to go
carefully through all the source code to find all of them. Then the second stage of this task
was to create those functions that were missing.
The implementation follows strict rules of coding style applied in freeIPA1 project and
projects associated to it, as is also SSSD. This is thus to make sure the code will be readable
and understandable, because SSSD is an open-source project and anyone can contribute to
it.
Main goal of the design phase was to keep the source code as minimal and general
as possible, to ensure that any future extension or modification to code will be easy and
just a matter of simple addition of a new module for new object without any interference
with the application’s core. The same attitude is used for eventual extension in amount of
information, which is handed down to user, where the only thing needed to do so is to add
attributes identification to inner complete enumeration of attributes and application will
automatically handle the rest of the work. Implementation uses three main libraries: for
memory allocation, argument parsing and for hash table administration. The tool also uses
various functions from other SSSD modules to setup its basic functions as is connection to
configuration database and database with data itself.
1
http://freeipa.org/page/Coding Style
31
6.4
Tool Design
Complete concept of the application is quite straightforward. User enters specification of
what kind of object is the tool going to search for, together with a particular identification
of this object and the tool will print out, in case the object exists in database, information
about it or an error message, if it does not. The biggest question concerning design was
which type of identification will be chosen for objects as a key to the search function.
Whether the tool will offer just usage of unique identifiers which are for the current list of
objects name, unique identification number (UID), group identification number (GID) and
port, therefore the result will always find just one particular object and print information
about it or if the tool should be able to search according to any attribute that object
can possibly have, so in this case, there could be a situation, where more than one object
matches the input parameters.
After discussion with other developers and after consideration of number of given attributes present within objects, it was decided, that the tool in this version will support just
unique identifiers with option to get information about all the objects of one kind, stored
in database. This is because main purpose why anyone will use the application will be to
find out detailed information about objects and not to find which objects have a specific
value of attribute and if, there is the option to print out all of the object and the results
can be easily filtered by any command-line features like grep2 .
Second issue that had to be taken under deep consideration was which attributes and
what number of them will be available to be printed out. As there are many and many
attributes that each object on basis of standard LDAP classes can have and as some of
them are very peripheral for everyday usage a big filtration was made and just the “must
have” attributes stayed, in other words those attributes that other applications in Linux
environment usually print out about these objects. As was described in previous section,
the tool is very flexible and modular, therefore adding any additional attributes will be no
problem.
The last addition that was made to the application’s design was an option, that allows
user to hide some of default parameters, which would be normally printed out on the output,
making the result list much more lucid, especially in cases when all the objects are going
to be printed out.
6.5
6.5.1
Implementation
Initialization
The program starts by typical argument processing with help of library popt.h3 , that offers
very user friendly set of functions and preset macros to easily process arguments given by
user through command line. Next phase is to validate given arguments, because logically
there are many forbidden combinations, because each object can be identified just by few
specified identifiers 6.1. To process more complex arguments as are attributes that user
wants to see on output so as to process type of identifier which will be used, serves a
specially created function, that simply parses all the arguments and depending on input
determines what kind of identification will be used and saves this information into main
system structure query tool ctx, which is used not only to store this information, but
2
3
man grep, http://unixhelp.ed.ac.uk/CGI/man-cgi?grep
http://docs.fedoraproject.org/en-US/Fedora Draft Documentation/0.1/html/RPM Guide
32
mainly core data as is a link to confdb database, information about domains and list of
system databases, all mentioned later.
Object
user
group
netgroup
autofsm
sudo rule
service
ssh host
domain
Identifiers
name, UID
name, GID
name
name
name
name, port
name
name
Table 6.1: Object Identifiers
For a memory allocation we do not use standard C malloc() and its relative functions,
but the library talloc.h4 , which is a hierarchical, reference counted memory pool system
with destructors, that bring easiness for otherwise complicated way how to allocate and free
memory in C, which in bigger project grows to very messy thing and can be a source of many
memory leaks. Thanks to hierarchical system, we only need to take care of deallocating the
root object, that is connected to its children by links created upon their allocation and the
library takes care of deallocating the whole connected tree of allocated memory.
As next we proceed to connection to SSSD database, from here reffered to as “sysdb”,
by using function init domains() borrowed from another tool sss cache. This function
firstly establishes connection to confdb, which includes all necessary information and settings to enable connection to sysdb and as a next step finally connects to sysdb. All this
functionality is done by functions already implemented in SSSD5 .
Attributes saved in SSSD database are identified by names(strings) written rather
in computer-like style, so for example UID number inside SSSD is identified as attribute
uidNumber. But these names would not be very nice for users to read on output, that is
reason why all attributes that sss query offers to be displayed are mapped to human readable form. For this approach we use a hash table, which key-value entries have format of:
<string, string>(SYSDB <attribute>, human readable SYSDB <attribute>)
Thanks to use of hash table, we can later profit on very fast and simple way how get the
right translation for SYSDB attribute to human readable form. To use and work with hash
tables, we use library called ding-libs (libdhash).
Now we are in a stage where we already know what type of object we will be looking
for and we checked whether user also used correct identifier, so now the only thing that is
left is the search for object itself.
6.5.2
Query on Basic Objects
In this stage we get to querying itself. There are many functions already implemented in
SSSD that offer a way how to get information about objects stored in database. If we want
to make a query, we need to call some of lbd functions on the lowest level, since ldb is the
framework that allows us to work with database. The building stone of every functions
4
5
http://www.talloc.samba.org
sssd-1.9.91/src/db/sysdb.h
33
that gets data from sysdb is ldb search that is very similar to ldap search, so we need
to pass base dn, search scope and filters (3.1) as arguments to it and it will provide us
with results of search as its return value in special structure ldb result. This structure
contains a pointer to array of the results from the search and is easily accessible for further
work.
There are many functions that are wrappers around this basic and very general function
for most of object in sysdb, each of these functions has its own specialties as each object has
different unique identifier and needs to be treated differently in means of types of attributes
it has or where in sysdb is this object located. These functions are widely used is sss query
and in cases where these functions for certain object are not available, sss query uses basic
ldb search to get results.
The only difference between functions working with one certain object and those working
with whole class of objects is, that there have not been implemented any functions, to get
information about group of objects in SSSD, therefore ldb search is always used in this
case. We handle the results in a basically same way, we just have to iterate through complete
list of results.
6.5.3
Domain and Subdomain Information
Different approach is used with domains. Since we have all the data about domain or domains stored in special structure since initialization, we do not need to make any additional
queries on sysdb.
It is quite easy with subdomains again, each structure with domain information includes also pointer to array of subdomains, that are in every view similar to domains, just
their location in tree hierarchy is one level lower than domains. It is worth mentioning,
that subdomains can again have subdomains, so there can be whole nested structure of
subdomains.
6.5.4
Printing Results
Now when we already have our query results, we just need to display them to users. Because
sss query works as an console application and therefor lacks GUI, results are printed in text
form on standard output. If user did not specified attributes he would like to see on output
a default set of attributes will be printed out. In case of query on all objects of certain
type, results are printed out one by one, visibly divided and provided with label saying
from which domain they come from and what is their number in list of results.
Print function is quite straight forward, we have an array of attributes that will be
displayed on the output. We iterate through them and with each we first find the human
readable name, that will go on the output together with its sysdb internal name and of
course its value . This value is gathered from the result message that ldb search gave us
using another ldb function ldb msg find attr as string and then the complete information about attribute is printed out.
Nevertheless the output is done just in a text form, sss query tries to format and display
results or any massages in a way that it looks nice and it is easy to take in. So little bit of
ascii graphic“ 6 is used to separate results and to create a header for each one, so the user
”
is provided with all the necessary information in understandable and easy to read form.
6
Graphical object made just from ascii characters
34
6.5.5
Errors
Generally there are two types of errors that can occur during run of the application. Firstly
there are system errors, that are caused by wrong configuration of SSSD or because there
was some problem inside the application and secondly errors caused by wrong usage of
the tool, which means that user inserted wrong or non-existing arguments of used invalid
combination of arguments. All the errors, which can occur are stated in appendix D.
6.6
Tests
To test the tool, there were created few tests, that at first place tested in sequence all the
program’s argument combinations. Since there are really many possible combinations and
not all of them are valid and furthermore each invalid combination falls within one of the
different error group, it was necessary to test all of the combinations, to make sure that
the tool will never start its function with invalid arguments given. Next of the tests filled
the database with objects from each group to see whether all the functions collected from
all around the SSSD really work together and bring the desired result. Functions that
take care of connecting to configuration database and database of objects itself have been
already included in unit tests of SSSD.
Since the tool uses LDB API, which has already been implemented in Samba project,
properly tested and used. There is no need to test them again. All the information and
results of LDB testing can be found on projects documentation page7 . An extract from
test that have been ran on the tool can be found in appendix F. there are results of mostly
all cases user can perform with tool, when using it.
7
http://wiki.samba.org/index.php/Samba4/LDBIntro
35
Chapter 7
Conclusion
Reader of this thesis was introduced with overall information about databases, their different models with focus on those that are used the most these days, but we also did not
forget to mention those types that are not that widely used, but are slowly finding their
place in the modern, and in every moment developing, world of computers. We stopped for
more detailed information about LDAP and LDB and moved to description of SSSD, its
architecture, functions and its database.
The main output of this thesis is a tool for querying SSSD database, which is able to
query all different types of data stored in SSSD database and to offer SSSD administrators
the important information about them. This tool was developed with emphasis on very easy
usage and therefore offers very simple UI which allows very complex control of application.
I strongly believe that this tool will ease work of many people dealing with SSSD and
provide all the functionality that was expected.
This application offers a lot of functionality, but there is a space to merge it with other
already existing tools for SSSD administration so as with other tools, that has not yet been
developed and might be needed. Thanks to its design, it will be also very easy to make
extensions to it, if needed. Therefore its current stage might not be ultimate as application
will change in future as will SSSD with newer versions that will be introduced.
36
Bibliography
[1] C.J. Date. An Introduction to Database Systems. Addison-Wesley Publishing
Company, 1979. ISBN 0-201-01530-7.
[2] R. Haines. The SELinux Notebook - The Foundations. http:
//www.freetechbooks.com/the-selinux-notebook-the-foundations-t785.html,
2008.
[3] Red Hat. Fedora documentation. http://www.docs.fedoraproject.org/.
[4] J. Hrozek. SSSD Wiki - Design documents. https://fedorahosted.org/sssd/wiki.
[5] Hrozek, J. and Nagy, M. FreeIPA and SSSD. Presentation at Red Hat Developers’
Conference, 2009.
[6] Richard D. Irwin. Database Management - Theory and Application. Irwin, 1990.
ISBN 0-256-07829-7.
[7] ITU-T. The Directory - Overview of concepts, models and services. X.500, August
2005.
[8] ITU-T. The Directory: Models. X.501, August 2005.
[9] P. Neubauer. Graph Databse, NOSQL and Neo4j.
http://http://www.infoq.com/articles/graph-nosql-neo4j, May 2010.
[10] P. Sadalage and M. Fowler. NoSQL Distilled: A Brief Guide to the Emerging World
of Polyglot Persistence. Addison-Wesley, 2012. ISBN 0-321-82662-0.
[11] S. Sorce. LDB and the LDAP server in Samba4. Samba experience conference, 2006.
[12] A. Tatiyants. XML Databases.
http://www.codeproject.com/Articles/370869/XML-Databases, 2012.
[13] M. Wahl, T. Howes, and S. Kille. Lightweight Directory Access Protocol, 12 1997.
RFC 2251.
[14] K. Wong. Introduction to object-oriented databases. MIT Press, 1948.
ISBN 0-262-11124-1.
[15] K. Zeilenga. Lightweight Directory Access Protocol (LDAP):Directory Information
Models, 6 2006. RFC 4512.
37
Appendix A
DVD contents
• Directory documentation
Contains LATEX source codes of bachelor thesis and a complete work in PDF format.
• Directory sss query
Contains source codes of SSSD 1.9.91, patch to add sss query to it, manual page of
sss query in XML format, bash script for instalation of SSSD and putting it to state
ready for use and few other files with exemplary data for the database.
38
Appendix B
Manual
This manual describes how to compile and run the sss query tool. This tool was developed
and tested on OS Fedora 181 . To install and configure SSSD version 1.9.91, patch it to
contain sss query and insert some test data into database, there is a prepared bash script
install.sh, that will take care of all the job. In case that this script fails for any reason,
please follow these steps:
B.1
Unpacking
Project is packed in .tar.gz format, to extract it, use tar. This will extract whole SSSD
into directory called sssd-1.9.91. A patch containing sss query was already applied on this
version, so there is no need to patch.
$# tar -xzf sssd-1.9.91.tar.gz
B.2
Dependencies
SSSD uses many libraries, that might not be installed on Fedora 18 by default. All the
necessary libraries are mentioned in BUILD.txt. In order to install all of them use:
$# yum install openldap-devel gettext libtool pcre-devel c-ares-devel \
dbus-devel libxslt docbook-style-xsl krb5-devel nspr-devel \
libxml2 pam-devel nss-devel libtevent python-devel \
libtevent-devel libtdb libtdb-devel libtalloc libtalloc-devel \
libldb libldb-devel popt-devel c-ares-devel check-devel \
doxygen libselinux-devel libsemanage-devel bind-utils libnl3-devel \
gettext-devel glib2-devel
$# yum install libcollection-devel libdhash-devel
libpath_utils-devel libref_array-devel
1
http://www.fedoraproject.org
39
libini_config-devel \
B.3
Compiling
To build whole project use these simple orders. Autotools and Makefile will take care of
everything by itself:
$# autoreconf -i -f && \
./configure && \
make
B.4
Exemplary data
To insert some exemplary data into database for purposes of testing, copy all the contents
of directory exemplary data into /var/lib/sss/db. This can be easily achieved by using:
$# cp * /var/lib/sss/db
in directory exemplary data.
B.5
Running the tool
Now the tool is ready to be run. Database will include few users and groups in domain
example.com. To run the tool, go to SSSD root directory and run:
$# ./sss_query <object_type> <identification> <attributes_to output>
40
Appendix C
Man page
SSS_QUERY(8)
SSSD Manual pages
SSS_QUERY(8)
NAME
sss_query - perform query on SSSD database
SYNOPSIS
sss_query {options} {identifier} [set of attributes]
DESCRIPTION
sss_query allows user to query certain object or all object of the same
class from SSSD database and displays results on the output.
OPTIONS
-u,--user
Query on user(s).
-g,--group
Query on group(s).
-n,--netgroup
Query on netgroup(s).
-s,--service
Query on service(s).
-m,--autofsmap
Query on autofs map(s).
-b,--sshhost
Query on ssh host(s).
-r,--sudorule
Query on sudo rule(s).
41
-d,--domain
Query on domain(s).
-o,--subdomain
Query on subdomains.
-?,--help
Display help message and exit.
IDENTIFICATOR
-N,--name name
Object name. Tool also supports FQ names.
-U,--uid UID
Object UID.
-G,--gid GID
Object GID.
-P,--port port
Service port.
-I,--ident identificator=value
Searches based on identificator (one of previous options) and
value.
-A,--all
Search for all objects of the same class.
ATTRIBUTE_LIST
-S,--show attribute_name,...
Defines which attributes will be printed out.
SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5),
sssd-ipa(5), sssd-ad(5), sssd-sudo(5),sss_cache(8), sss_debuglevel(8),
sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8),
sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8),
sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8),
sss_ssh_knownhostsproxy(8),pam_sss(8).
AUTHORS
The SSSD upstream - http://fedorahosted.org/sssd
SSSD
04/29/2013
42
SSS_QUERY(8)
Appendix D
Errors
System Errors
Super user privilege
Message:“You must be root in order to run this application!”
All the tools in SSSD can be run only by user with super user rights.
Confdb connection
Message:“Could not initialize connection to the confdb”
There was problem loading confdb, as default, SSSD expects confdb to be in /var/lib/sss/db,
if you want to change the path, use –with-db-path argument during SSSD build.
Domain connection
Message:“Could not initialize domains”
An error with domains occurred, check your domain configuration.
Sysdb connection
Message:“Could not initialize connection to the sysdb”
Again, you need to check if sysdb database is correctly configured and set.
Locale set error
Message:“Error setting the locale”
Locales contain information on how to interpret and perform certain input/output and
transformation operations taking into consideration location and language specific settings,
therefore check you environment’s locale settings.
Hash table error
Message:“Cannot add entry to hash table”
Some problem occurred with adding hash to hash table.
Argument Errors
One or all objects
Message:“Please chose to search either for one object or for all, not both”
You can select either one object by specifying it using one of the <object type>from E.2
or you can use -A to display all objects. Using both parameters will cause error.
43
Too many identifications
Message:“Please use one type of identification”
You have to use one type of identification from <identification>in E.2, it is not possible to
use more than one.
Object not selected
Message:“Please chose one type of object”
You have to chose one type of object from <object type>E.2 to be searched.
Identification unspecified
Message:“Please enter identification of object you want to find”
You forgot to insert name/uid/gig/port of the object.
Direct identification mixed with indirect
Message:“Please chose just -N/-U/. . .(–name/–uid/. . .) or -I(–ident) option”
You can use either direct object identification or indirect using -I, not both at the same type.
Wrong object identification
Message:“You can use UID/GID/port number just for identifying users/group/services!”
All the objects can be identified by their name, but just certain objects can be identified
using UID, GID or port number.
Invalid format of indirect identification
Message:“Please insert valid pair of attributes: name=value”
You did not follow the needed format of indirect identification.
Too many output attributes
Message:“Too many attributes to show”
At maximum, there are only 5 attributes that an object have. Therefore by inserting more
than 5, program will end with error.
Invalid indirect identification
Message:“Invalid identification type”
There are only options name, uidNumber, gidNumber or portService for indirect identification and you used none of them.
44
Appendix E
Application Constants, Flags and
Arguments
Entry type
users
groups
netgroups
service
autofsm maps
ssh hosts
sudo rules
domains
subdomains
SSSD internal macros
SYSDB NAME, SYSDB UIDNUM,
SYSDB GIDNUM, SYSDB HOMEDIR,
SYSDB SHELL
attributes
name, uidNumber,
guidNumber,
homeDirectory,
loginShell
SYSDB NAME, SYSDB GIDNUM
name, gidNumber
SYSDB NAME, SYSDB UUID
name, nsUniqueId
SYSDB NAME, SYSDB USN,
name, entryUSN,
SYSDB SVC PORT,
ipServicePort,
SYSDB SVC PROTO
ipServiceProtocol
SYSDB AUTOFS ENTRY KEY,
name, automountInSYSDB AUTOFS ENTRY VALUE
formation
SYSDB SSH HOST OC,
sshHost, sshKnownSYSDB SSH KNOWN HOSTS EXPIRE, HostsExpire,
SYSDB SSH PUBKEY
sshPublicKey
SYSDB SUDO CACHE AT CN,
cn, sudoUser,
SYSDB SUDO CACHE AT USER,
sudoHost,
SYSDB SUDO CACHE AT HOST,
sudoCommand,
SYSDB SUDO CACHE AT COMMAND, sudoOption
SYSDB SUDO CACHE AT OPTION
name, provider, SYSDB VERSION
name, provider,
version
SYSDB NAME,
name, realName,
SYSDB SUBDOMAIN REALM,
flatName, domainID
SYSDB SUBDOMAIN FLAT,
SYSDB SUBDOMAIN ID
Table E.1: Default entry attributes
45
short opt.
-u
-g
-n
-s
-m
-t
-r
-d
-a
-N
-U
-G
-P
-I
-A
long opt.
–user
–group
–netgroup
–service
–autofsmap
–sshhost
–sudorule
–domain
–subdomain
–name
–uid
–gid
–port
–ident
–all
value format
no value
description
type of object
to be searched
example
-u
[name]
[uid]
[gid]
[port]
[identificator]=[value]
no value
entry
identification
-N bambusekd
–uid=32568
query all
objects of
chosen type
Table E.2: Mandatory flags
short opt.
-S
long opt.
–show
value format
[attribute name]+
description
If set, just specified
attributes will be
displayed, otherwise
attributes from
default set E.1 will
be displayed.
Table E.3: Optional flags
46
example
-s name, mail
Appendix F
Test results
Find user - all attributes
$# ./sss_query -u -N bambusekd
$# === Showing requested object ===
Name(name):
bambusekd
UID number(uidNumber):
1063200001
GID number(gidNumber):
1063200001
Home directory(homeDirectory):
/home/bambusekd
Shell(loginShell):
/bin/sh
Find user - using FQ name
$# ./sss_query -u -N bambusekd@example.com
$# === Showing requested object ===
Name(name):
bambusekd
UID number(uidNumber):
1063200001
GID number(gidNumber):
1063200001
Home directory(homeDirectory):
/home/bambusekd
Shell(loginShell):
/bin/sh
Find user - just UID and name
$# ./sss_query -u -N bambusekd -S uidNumber,name
$# === Showing requested object ===
UID number(uidNumber):
1063200001
Name(name):
bambusekd
Find all users
$# ./sss_query -u -A
$# === Showing all users in domain example.com ===
=== entry: 0 === domain: example.com ===
47
Name(name):
bambusekd
UID number(uidNumber):
1063200001
GID number(gidNumber):
1063200001
Home directory(homeDirectory):
/home/bambusekd
Shell(loginShell):
/bin/sh
=== entry: 1 === domain: example.com ===
Name(name):
krausj
UID number(uidNumber):
1063200004
GID number(gidNumber):
1063200004
Home directory(homeDirectory):
/home/krausj
Shell(loginShell):
/bin/sh
Find all users - just UID and shell
$# ./sss_query -u -A -S uidNumber,loginShell
$# === Showing all users in domain example.com ===
=== entry: 0 === domain: example.com ===
UID number(uidNumber):
1063200001
Shell(loginShell):
/bin/sh
=== entry: 1 === domain: example.com ===
UID number(uidNumber):
1063200004
Shell(loginShell):
/bin/sh
Show domain info
$#./sss_query -d -N example.com
$# Domain name: example.com
Domain provider: ipa
Domain version: 0.14
Error - no object selected
$# ./sss_query
$# Please chose one type of object
Error - too many arguments
$#./sss_query -u -g
$# Please chose one type of object
48
Find non existing object
$#./sss_query -u -N smithj
$# === Object not found! ===
Find object in non existing domain
$#./sss_query -u -N bambusekd@fit.cz
$# === There is no domain fit.cz ===
49