tiger-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tiger-devel] [RFC] potential definitions for check_accounts, check_pas


From: rbradetich
Subject: [Tiger-devel] [RFC] potential definitions for check_accounts, check_password, and check_passwortformat modules.
Date: Wed, 2 Jul 2003 11:58:02 -0600
User-agent: Mutt/1.5.3i

Hello all,

I slept on the problem I was having with the check_accounts, check_password, 
and check_passwordformat modules and
I have an idea how to reduce the confusion (atleast for me :)).


I propose to define the modules like this:

        check_password - This module handles the checks that are directly 
related to the password entries.
                Examples include:
                        - Login does not have a valid shell
                        - Duplicate home directory check
                        - Password aging check
                        - Blank password check
                        - Etc.

        check_accounts - This module handles checks related to password entries 
(i.e. the meat of the check is
                         outside of the password file).
                Examples include:
                        - Home directory permission checks.
                        - Permisions on shell initialization files.
                        - Permissions on dotfiles
                        - Etc.

        check_passwordformat - This module handles sanity checks on the format 
of the password (/etc/shadow, etc) files.
                               My goal for this module is to provide a 
replacement pwck, if pwck is not available on 
                               the system.
                Examples include:
                        - User mis-match between /etc/password and /etc/shadow.
                        - Blank lines in the /etc/password, /etc/shadow files.
                        - Invalid number of fields in /etc/password, 
/etc/shadow files.
                        - Etc.


I believe defining these modules to these definitions (or similar definitions) 
will reduce the confusion on where new
security checks should be added.  I know I am guilty of adding to this problem, 
but the fact a check for a blank password
entry is present in all 3 modules indicates some level of confusion :)

I have all the checks mapped of where they currently exist and where I think 
they belong in these three modules based
upon these defintions.  I plan on working on a patch to move the checks around 
and remove the duplicate checks this
afternoon/evening.  I am hoping the patch will illustrate the confusion I am 
seeing, so we can collectively decide
on how to eliminate this confusion.

Thanks,

- Ryan

PS. The blank password check is not the only duplicated check, just one I 
helped contribute to ... so I picked it :)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]