Next Previous Contents

9. List of specification not dispatched

#Specbeg: user category ([userconf.h,8])

        #define TUSER_STD       1
        #define TUSER_PPP       2
        #define TUSER_SLIP      3
        #define TUSER_UUCP      4
        #define TUSER_SPECIAL   5
        #define TUSER_POP       6
        #define TUSER_ADMIN     7

#Specification: /etc/group / strategy ([,21])

/etc/group is read "by hand" instead of using getpwent() to avoid getting all those NIS entries. This is done when editing local group account.

#Specification: /etc/passwd / strategy ([,52])

/etc/passwd is read "by hand" instead of using getpwent() to avoid getting all those NIS entries. This is done when editing local user account.

#Specification: /etc/passwd / strategy ([,199])

/etc/shadow is read "by hand" instead of using getpwent() to avoid getting all those NIS entries. This is done when editing local user account.

#Specification: configurator / setuid root ([,414])

The configurator (anything-conf) can be set setuid root. It will allows normal users to get in and then will ask for the root password at the proper time. This strategy make the system friendlier. It allows normal user to inspect the configuration (if allowed) and when finding something odd, use the root password (if known) to fix things, The idea here is that we generally think first about getting somewhere and later about the permissions needed to get there. The nice thing about this scheme is that this program will deny root access automaticly after some time. If you don't like this, then don't set it setuid root. It will operate correctly and won't bug you with password.

#Specification: crontab / enabling en entry ([,52])

The crontab files do not have a reliable way to enable/disable an entry. While we can comment out one line, there is no standard way to do it and let linuxconf differentiate a disabled entry from a simple comment. Linuxconf is using a special "token" which should make it obvious that this is not an ordinary comment. Disabled entry are prefixed by the sequence #-#. This trick is now used for crontab and should make their way into other configuration file.

#Specification: html password dialog / end of page ([,55])

The admin may supply a file /etc/passwd.htmlend. This file must contain html and will be inserted in the html dialog letting a user change his password.

#Specification: html password dialog / introduction ([,15])

The admin may supply a file /etc/passwd.htmlintro. This file must contain html and will be inserted in the html dialog letting a user change his password.

#Specification: password / strategy / by hand ([,69])

To support transparently standard and shadow password without recompiling, linuxconf read manually the /etc/passwd and /etc/shadow files. This is causing problem for NIS user though. This will have to be fixed.

#Specification: password policies / user may change ([,1254])

A user may change his password if -The minimum time since the last change has elapsed. -The minimum time is lower than the maximum password duration

#Specification: privilege / presentation / order ([,263])

Privilege are presented in alphabetical order. First they are sort by section name and then internally in each section by title. A trick is provided to force some section before others. If a section title start with a digit, followed by a -, then this is used for the sort, but it is not displayed. When defining privileges in different section and you want to have those section is a specific order, then give the a title like

            1-this is the title.
Title are given in the declaration of a new privilege. The same mecanism apply to privilege title.

#Specification: privileges / default privilege ([,410])

If a default privilege is defined, it overrides any privileges.

#Specification: privileges / intro ([,14])

The privilege system of Linuxconf let you give special power to end user. Linuxconf manage quite a few feature of a system and each component of linuxconf can associate itself with a special privilege. When trying to perform something special, the component ask permission to the perm_access() function passing it the PRIVILEGE object which fit its security scheme. When perm_access() is called, either the root password or the user password must be supplied. If the user has this privilege, then operation can continue. The privilege feature is unique to linuxconf. A privileged user has no special UID or GID. Out of linuxconf, it is a plain normal users. This concept is expect to grow in the following directions

            -Assigning privilege to group.
            -Allowing some flexibility to user authentication. For exemple
             one user won't have to provide his password if he is accessing
             linuxconf in such or such context. This would help make linux
             much more user friendly.
            -Assigning password to privilege
PRIVILEGE objects are always static and link together, so we know at run time all the privilege that exist in the application. This is used to dunamically create the USER configuration dialog.

#Specification: PRIVILEGES / principle ([,348])

All PRIVILEGEs are static object. It is convenient to manage them in an array (PRIVILEGES). This array use the never_delete() mecanism to prevent deletion of the objects it contain. So a static PRIVILEGE may be store in a PRIVILEGES object without constraint.

#Spécification: PRIVILEGE_TASK / principle ([,91])

Each sub-system needing to create privilege dynamicly (not simply using "static PRIVILEGE" variable may define a PRIVILEGE_DECLARATOR object. The only purpose of this object is to pass a pointer to one function which will be called when privilege editing is taking place to make sure the privileges of this subsystem are created and up to date.

#Specification: PRIVI_FEATURE / principle ([,373])

A PRIVI_FEATURE is a PRIVILEGE which is not used to grant access but to control behavior. It is used generally only with the function perm_checkpriv() to see if a user may do or see something. There is no authentication checkbox associate with it. There is generally a related PRIVILEGE which is test in the application with perm_access(). For example, a PRIVILEGE may be defined to grant access to UUCP management and let the user control for example the schedule of calls and a PRIVI_FEATURE indicates if the user may see the full information, including the chat configuration (with password).

#Specification: root access / password validation ([,197])

When the admin/user must provide the root password, he has 3 chances.

#Specification: root access / timeout ([,313])

When the user select a configuration task, the password for root must be supplied. This "validation" is good for 2 minute. It means that the user may do several configuration in one minutes without being asked for the root password every time. If the user wait a minute or more, the password will be asked again. Look safe and user friendly to me.

#Specification: updating password / module messages ([,1210])

The module message API is used when a user password is changed. The message "chgpasswd" is sent with the following arguments:

        user id
        new password (clear text)
        locked account (1 for lock, 0 for unlock)
        domain  (/ for the main, a domain name for virtual email domain)

#Specification: user / home directory / owner ([,347])

userconf check that the home directory of a user is own (gid and uid) by him except for special account ( administrative, PPP, uucp, etc...) where we generally allocate the same directory to a bunch of users.

#Specification: user account / login id / lexical validation ([,596])

The following character are invalid in a login id

        space, : ( ) [ ] ' " | & ; ` *
and any ASCII character below 32 (space)

#Specification: user account / passwd / non shadow locking ([,1165])

When locking a non-shadow user account, linuxconf insert a '*' in front of the password, making it useless. When the account is unlock, linuxconf remove the '*' and the old password is effective again. This trickery may not work for all module (SMB password may be lost).

#Specification: user account / privilege / set default ([,750])

When editing a user account, we call the function perm_setdefprivi to register the default privilege. This is done to help co-manager do there tasks withoug being forced to pass PRIVILEGE pointers around all the time. This is annoying as it does not allow a sub-process to drop privilege easily (just by setting the PRIVILEGE pointer to NULL for example).

#Specification: user account / shell selection / list ([,764])

For different reasons, the list of shell available when managing an account is limited. The admin has to choose one from the list. This list is managed by linuxconf anyway. Here are those reasons -Selecting a shell for normal user which is not defined in /etc/shells will cause different problem later, such as prohibiting ftp access for that user. -Special accounts like PPP and POP often have a co-administrator. This one must be limited somewhat as he would be able to select a special program when creating a POP acount and this account would easily grant him root access. So the story is "Specify with linuxconf which shells are available for PPP, SLIP and normal USER and by happy later".

#Specification: user account / shell selection / POP account ([,781])

POP account have /bin/false as a shell and it is not configurable. For this reason, the field "command interpreter" is not even shown for those type of users.

#Specification: user accounts / delete / removing home ([,552])

When deleting a user accounts, the admin is allowed to archive, delete or keep the user home directory. The scripts used to delete or archive the home directory will only perform there task if the user do own the directory. So if a bunch of users are mapped to a common home (pop users generally), then the directory won't be deleted.

#Specification: user accounts / privileges / chown home ([,419])

We drop privilege since only root is allowed to change ownership of a home directory USERS::editone() had set a default privilege to support co-managers.

#Specification: user creation / group creation ([,1020])

When creating a new group on the fly for a user account, we try to allocate a GID equal to the UID. If the GID is already used, the first free one is used.

#Specification: user creation / home directory ([,433])

The HOME directory of a new user is created with permission defined in the policies (default 0700) or defined for the group. The content of the directory /etc/skel is copied in the directory, respecting the permission setting of /etc/skel. All file copied will belong to the new user.

#Specification: user edit / bad html dialog ([,985])

This is a good exemple of a bad dialog (or at least complex dialog) for html mode All side effect of the dialog must be done at the exit. The do_sethome kludge is there just for that.

#Specification: user record / gid / format ([,488])

GID may be entered either as a string (a group name) or as a number.

#Specification: userconf / /etc/shells & getusershell() ([,44])

Shells available to configure user accounts are defined by getusershell() (which reads /etc/shells optionnally). It is assumed that the first entry in /etc/shells is the default shell (When the field is empty in /etc/passwd).

#Specification: userconf / automatic allocaion of uid ([,269])

We multiply gid by 500. From there we search in all user id and allocate the first uid in the range. We don't allocate into holes (unused uid between used one) to avoid uid reuse (and a security hole). This has shown problematic. Now linuxconf allocated the a new UID as the next one to the one with the highest uid number.

#Specification: userconf / etc/passwd ([,19])

/etc/passwd is the user database. Its permission flags are always set to 0644 when rewritten.

#Specification: userconf / groups / default for creation ([,150])

The default group is "users". If this group does not exist. then the group "group" is used. If none of those group exist, then no default group is proposed to the user.

#Specification: userconf / groups / group ID allocation ([,273])

When creating a new group, the group ID may be left blank. An unused group ID will be allocated. The first one unused will be allocated. We assume that a maximum of 65000 group may be configured.

#Specification: userconf / net password / rejected ([,1068])

New password are validated with some rules to ensure they are difficult enough. Here are the rules.

        -6 chars minimum
        -Must have at least one non-letter character

#Specification: userconf / passwd clone ([,1369])

userconf can be a clone of the /bin/passwd program, If the proper symlink is done. When a user attempt to change his own password, the program prompt for the current one.

#Specification: userconf / password / checking ([,1095])

userconf check the minimum length and the amount of non alpha character in a new password. If the new password does not fullfill the local policies, it is rejected.

#Specification: userconf / pop account ([,64])

All pop account are set with the group popusers (POP_GROUP). If this group does not exist, it is created The user is prompt about that. POP only users are getting the shell /bin/false denying interactive logins.

#Specification: userconf / ppp account ([,49])

All ppp account are set with the group pppusers (PPP_GROUP). If this group does not exist, it is created The user is prompt about that.

#Specification: userconf / principal ([,38])

The userconf program allows you to edit/create/delete user accounts and groups.

#Specification: userconf / slip account ([,36])

All slip account are set with the group slipusers (SLIP_GROUP)

#Specification: userconf / user / home directory ([,310])

userconf do not allow a user to have an empty directory nor a directory which point to something else than a directory.

#Specification: userconf / user account / root bin ... ([,443])

Some special account are simply left out of the configuration menu. These account are never edited. They make the list larger for no reason. Also account with special shells are not shown. This include accounts like uucp and slip. Theu are show in a separate menu. The same functionnality is used to edit those accounts, but the edition is trigerred from different menus.

#Specification: userconf / user account / semicolon ([,917])

A check is made to ensure that the user has not entered a : in any field during edition.

#Specification: userconf / user password / empty and * ([,1079])

Only root is allowed to set an empty password or one with only * in it. It will be refused (error message) for all other users.

#Specification: userconf / uucp account ([,22])

All uucp accounts are set with the group uucp (UUCP_GROUP)

#todo: userconf / groups and users / default for creation ([,156])

It is not clear if a default setup should exist such as /etc/default/useradd and could be edited by userconf. Currently, we assumed that the default user group is 1.

Next Previous Contents