Спонсоры:
Хостинг:
login_close login_getcapbool login_getcaplist login_getcapnum login_getcapstr login_getcapsize login_getcaptime login_getclass login_getclassbyname login_getpwclass login_getstyle login_getuserclass login_setcryptfmt - functions for accessing the login class capabilities database
Lb libutil
Entries in login.conf5 consist of colon `:' separated fields, the first field in each record being one or more identifiers for the record (which must be unique for the entire database), each separated by a `|' , and may optionally include a description as the last `name' Remaining fields in the record consist of keyword/data pairs. Long lines may be continued with a backslash within empty entries, with the second and subsequent lines optionally indented for readability. This is similar to the format used in termcap(5), except that keywords are not limited to two significant characters, and are usually longer for improved readability. As with termcap entries, multiple records can be linked together (one record including another) using a field containing `tc=' Ns Va <recordid> . The result is that the entire record referenced by <recordid> replaces the tc= field at the point at which it occurs. See getcap(3) for further details on the format and use of a capabilities database.
The
login_cap
interface provides a convenient means of retrieving login class
records with all
tc=
references expanded.
A program will typically call one of
login_getclass (,);
login_getpwclass (,);
login_getuserclass ();
or
login_getclassbyname ();
according to its requirements.
Each of these functions returns a login capabilities structure,
Vt login_cap_t ,
which may subsequently be used to interrogate the database for
specific values using the rest of the API.
Once the
Vt login_cap_t
is of no further use, the
login_close ();
function should be called to free all resources used.
The structure of Vt login_cap_t is defined in In login_cap.h , as:
typedef struct {
char *lc_class;
char *lc_cap;
char *lc_style;
} login_cap_t;
The
Fa lc_class
member contains a pointer to the name of the login class
retrieved.
This may not necessarily be the same as the one requested,
either directly via
login_getclassbyname (,);
or indirectly via a user's login record using
login_getpwclass (,);
by class name using
login_getclass (.);
If the referenced user has no login class specified in
/etc/master.passwd
the class name is
NULL
or an empty string.
If the class
specified does not exist in the database, each of these
functions will search for a record with an id of
`default'
,
with that name returned in the
Fa lc_class
field.
In addition, if the referenced user has a UID of 0 (normally,
`root'
,
although the user name is not considered) then
login_getpwclass ();
will search for a record with an id of
`root'
before it searches
for the record with the id of
`default'
The
Fa lc_cap
field is used internally by the library to contain the
expanded login capabilities record.
Programs with unusual requirements may wish to use this
with the lower-level
getcap ();
style functions to access the record directly.
The
Fa lc_style
field is set by the
login_getstyle ();
function to the authorisation style, according to the requirements
of the program handling a login itself.
The
login_getclassbyname ();
function is the basic means to get a
Vt login_cap_t
object.
It accepts two arguments: the first one,
Fa name ,
is the record identifier of the
record to be retrieved; the second,
Fa pwd ,
is an optional pointer to a
Vt passwd
structure.
First of all, its arguments are used by the function
to choose between system and user modes of operation.
When in system mode, only the system login class database is used.
When in user mode, the supplemental login class database in the
user's home directory is allowed to override settings from the system
database in a limited way as noted below.
To minimize security implications, user mode is entered by
login_getclassbyname ();
if and only if
Fa name
is
LOGIN_MECLASS
(`me'
)
and
Fa pwd
is not
NULL
Otherwise system mode is chosen.
In system mode, any record in the system database /etc/login.conf can be accessed, and a fallback to the default record is provided as follows. If Fa name is NULL an empty string, or a class that does not exist in the login class database, then the LOGIN_DEFCLASS record (`default' ) is returned instead.
In user mode, only the LOGIN_MECLASS record (`me' ) is accessed and no fallback to the `default' record is provided. The directory specified by Fa pwd->pw_dir is searched for a login database file called .login_conf and only the `me' capability record contained within it may override the system record with the same name while other records are ignored. Using this scheme, an application can explicitly allow users to override a selected subset of login settings. To do so, the application should obtain two Vt login_cap_t objects, one in user mode and the other in system mode, and then query the user object before the system object for login parameters that are allowed to be overridden by the user. For example, the user's .login_conf can provide a convenient way for a user to set up their preferred login environment before the shell is invoked on login if supported by login(1).
Note that access to the /etc/login.conf and .login_conf files will only be performed subject to the security checks documented in _secure_path3 for the uids 0 and Fa pwd->pw_uid respectively.
If the specified record is NULL empty or does not exist, and the system has no `default' record available to fall back to, there is a memory allocation error or for some reason cgetent(3) is unable to access the login capabilities database, this function returns NULL
The functions
login_getclass (,);
login_getpwclass ();
and
login_getuserclass ();
retrieve the applicable login class record for the user's passwd
entry or class name by calling
login_getclassbyname (.);
On failure,
NULL
is returned.
The difference between these functions is that
login_getuserclass ();
includes the user's overriding
.login_conf
that exists in the user's home directory, and
login_getpwclass ();
and
login_getclass ();
restrict lookup only to the system login class database in
/etc/login.conf
As explained earlier,
login_getpwclass ();
differs from
login_getclass ();
in that it allows the default class for a super-user as
`root'
if none has been specified in the password database.
Otherwise, if the passwd pointer is
NULL
or the user record
has no login class, then the system
`default'
entry is retrieved.
Essentially,
login_getclass (name);
is equivalent to
login_getclassbyname (name NULL);
and
login_getuserclass (pwd);
to
login_getclassbyname (LOGIN_MECLASS pwd .);
Once a program no longer wishes to use a
Vt login_cap_t
object,
login_close ();
may be called to free all resources used by the login class.
The
login_close ();
function may be passed a
NULL
pointer with no harmful side-effects.
The remaining functions may be used to retrieve individual capability records. Each function takes a Vt login_cap_t object as its first parameter, a capability tag as the second, and remaining parameters being default and error values that are returned if the capability is not found. The type of the additional parameters passed and returned depend on the type of capability each deals with, be it a simple string, a list, a time value, a file or memory size value, a path (consisting of a colon-separated list of directories) or a boolean flag. The manpage for login.conf5 deals in specific tags and their type.
Note that with all functions in this group, you should not call
free(3)
on any pointers returned.
Memory allocated during retrieval or processing of capability
tags is automatically reused by subsequent calls to functions
in this group, or deallocated on calling
login_close (.);
Time values are normally used for setting resource, accounting and session limits. If supported by the operating system and compiler (which is true of Fx ) , the value returned is a Vt quad (Vt long long ) of type Vt rlim_t . A value `inf' or `infinity' may be used to express an infinite value, in which case RLIM_INFINITY is returned.
This scheme allows the administrator to determine the types of authorisation methods accepted by the system, depending on the means by which the access occurs. For example, the administrator may require skey or kerberos as the authentication method used for access to the system via the network, and standard methods via direct dialup or console logins, significantly reducing the risk of password discovery by "snooping" network packets.
|
Закладки на сайте Проследить за страницей |
Created 1996-2023 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |