RFC: passdb redesign

Gerald Carter gcarter at valinux.com
Thu Nov 9 19:52:15 GMT 2000


Here is my current stat of mind wrt passdb/*


Problems
--------
  o current samba code is filled by functions that half
    use passdb backend and half use lp_..() defaults from
    smb.conf

  o two structure are used to represent an account entry.
    smb_passwd {} and sam_passwd{}.  These are used 
    inconsistently through the code.  The major differences 
    exist between the rpc subsystem and normal file/print 
    serving operations.


The Proposal
------------

  o Introduction of new smb.conf parameter to specify the
    shared library to be used for accessing account information.

	passdb module path = <filemname>

  o removeal of smb_passwd {} struct all together and 
    replacement of universal use of sam_passwd {} via an 
    opaque handle.

  o removal of passdb_ops {} structure.  This struct is for
    defining a set of functions pointers which currently 
    implement the passdb API.  This was previously needed
    as passdb backend support was chosen at compile time.
    This will be replaced by a well defined and documented
    interface shared between the passdb API and the loadable
    backend modules.  More on this in a minute.

  o Implement support for the following backends

      - smbpasswd 	(file)
      - TDBPWB 		(local DB)
      - LDAP 		(using AD schema)

    This means the experiemental NIS+ support  
    will be removed.  I think the general stand on NIS+
    is that it is dying (at least that is my opinion).


Advantages
----------

  o experiement with shared libraries for future use relating 
    to MS-RPC pipe support

  o a single interface allows a single tool to access/update
    all passdb backends without recompiling.  The same tool
    can put from smbpasswd and push to LDAP.

  o fewer compile time descisions (except on platforms 
    that do not support shared libraries of course).

  o More flexibility. For example, you can use 
    include parameters to validate clear text logons 
    against /etc/passwd and encrypted logons against LDAP
    from the same server.


Proposed Interface
------------------

Functions for manipulating sam_passwd struct (common to all
backends)

   pdb_get...(SAM_ACCOUNT_HND *hnd)
   pdb_set...(SAM_ACCOUNT_HND *hnd)

Backend storage access functions which must be implemented
by each passdb module

   /* search functions */
   SAM_ACCOUNT_HND* pdb_getsampwnam (char* username);
   SAM_ACCOUNT_HND* pdb_getsampwuid (uid_t uid);
   SAM_ACCOUNT_HND* pdb_getsampwrid (uint32 rid);
   SAM_ACCOUNT_HND* pdb_getsampwent ();


   /* create a new (and empty) sam_passwd struct */
   SAM_ACCOUNT_HND* pdb_new_sam_account ();


   /* write change to persistent storage */
   /* add a new acount*/
   BOOL pdb_add_sam_account (SAM_ACCOUNT_HND *hnd);
   /* update an account entry */
   BOOL pdb_update_sam_account (SAM_ACCOUNT_HND *hnd);
   /* delete an account entry */
   BOOL pdb_delete_sam_account (SAM_ACCOUNT_HND *hnd);

  

Note that certain functions have been left out of 
the interface (e.g. getsamdispnam()) as these are often 
convienence functions and can easily be added to the basic
passdb.c general interface.

I have started working on this already.  It is the 
first step to implementing group mapping and LDAP support
(officially).  Comments welcome.






Cheers, jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com/  VA Linux Systems   gcarter at valinux.com
       http://www.samba.org/       SAMBA Team          jerry at samba.org
       http://www.plainjoe.org/                     jerry at plainjoe.org

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )




More information about the samba-technical mailing list