On 3/17/2011 4:21 AM, Glenn Faden wrote:
On 3/16/11 10:34 PM, Martin Widjaja wrote:
So, if for some reason the initial account was deleted and replaced with an
LDAP account, and/or the nsswitch.conf was changed to specify ldap before
files, the userdel command would remove the LDAP account instead of the files
account. Same for usermod.
Are you saying that the userdel/mod commands can actually remove accounts on
the LDAP server?
Yes, but see below...
Or just that the LDAP account will be "disabled" locally?
If it indeed is modifying the LDAP account, it sounds a bit scary to me...?
It is a customer option.
OK. Great. I guess I just don't see this in today's userdel/mod, hence the
question.
It seems that LDAP modification should only be allowed from clients which have
proper authorization to modify LDAP server database, if such a flag exists (I
have heard this type of client control property/attribute exists on some UNIX,
can't remember which one, HPUX?).
The client system must have been previously been installed with the admin
credential of the LDAP server, and the server must have been installed to
enable such remote client to update its RBAC databases. This is done via
idsconfig on the server and ldapclient on the client.
Thanks for the info. Is there also going to be switch/flag for userdel/mod to tell if
it's supposed to be done against ldap or file, etc.? I think there's some variants of
userdel/mod that takes flags like "ldap=0|1" to denote this is ldap|not ldap.
Martin
--Glenn
Thanks,
Martin
On 3/16/2011 10:42 AM, Glenn Faden wrote:
Jan,
This looks good. FYI, there are several bugs relating to usermod/userdel that I
will be fixing for build 163:
6675187 useradd & roleadd should create new zfs home dir when parent is zfs
6996876 Buffer size to handle the user's home directory pathname not enough
to cover PATH_MAX
7020178 ERROR: Determine ZFS dataset for mountpoint /opt/tet failed.
performing useradd -m (create home)
7026867 useradd/mod/del needs to implement libzfs calls for zfs operations.
7022603 userdel(1M) is coring on double frees
To ensure that you are deleting the right account you should probably use the
-S files option explicitly. Although the current code defaults to files, in the
future, the code will follow nsswitch.conf by default. So, if for some reason
the initial account was deleted and replaced with an LDAP account, and/or the
nsswitch.conf was changed to specify ldap before files, the userdel command
would remove the LDAP account instead of the files account. Same for usermod.
--Glenn
On 3/16/11 7:36 AM, Jan Damborsky wrote:
Hi,
I would appreciate review of draft design
for unconfiguration of user/root account.
The outcome of this discussion will be reflected in [b].
Please provide your comments before COB 3/22.
Thank you,
Jan
1 Motivation
============
New System Configuration framework [a] currently provides
for post-install configuration of root and user account [b].
While this addresses requirements in area of fresh installation
of Solaris instance, it is not sufficient in scenarios where already
configured Solaris instance has to be reconfigured.
For instance in case of p2v migration or when non-global
zone is created by cloning of existing one.
In these cases, old configuration has to be removed and replaced
with new one applicable for new environment Solaris instance
is running in.
2 Scope
=======
The unconfiguration mechanism will provide for removal of user account
previously created by New System Configuration framework.
User accounts created by other mechanisms will remain untouched.
That will prevent from accidental removal of user accounts which
are not to be a subject of unconfiguration.
3 Problem statement
===================
Provide mechanism for removal of initial user account
and reverting configuration ofroot account previously
carried out by New System Configuration framework.
4 Requirements
==============
* remove initial user account from the system
* revert configuration of root account
5 Assumptions
=============
It is assumed that the mechanism will always run within target
environment and thus it will not be designed to work on alternate
root.
It allows to take advantage of mechanisms and tools which are
not alternate root aware - smf(5), userdel(1m).
6 Solution
==========
Start method of svc:/system/config smf service currently takes
care of post-install configuration of user and root account.
For purposes of unconfiguration, this smf service will be enhanced,
so that it could be plugged into smf unconfiguration framework-
see [c] for information about how smf unconfiguration framework
is supposed to work in general.
In particular, new smf 'unconfigure' method of svc:/system/config
smf service will be delivered.
That method will be responsible for removing user account previously
created by this service as well as it will clean up configuration
of root account.
In order to assure that only initial user account is removed,
new smf property 'configured_users' of type 'astring' will be
defined for svc:/syste/config smf service.
During configuration, smf start method will storelogin
of created user account into that property.
During subsequent unconfiguration, smf unconfigure method will
obtain user account to be removed from that property.
If that property is empty or does not contain valid login,
removal of user account will be skipped and warning
will be logged.
That property will be set to empty string after that.
Following chapters specify what in particular would be
covered by unconfiguration.
6.1 user account
----------------
For user account, smf unconfigure method will
* remove user from local databases:
passwd(4), shadow(4), group(4), user_attr(4)
* remove user entry from /etc/auto_home file
* remove home directory along with underlying ZFS dataset
* remove user entry from sudoers(4) file
smf method will consume userdel(1m) utility to accomplish
all tasks above except of the last one. smf method will
manually take care of removing user entry from sudoers(4) file.
6.2 root account
----------------
For root account, smf unconfigure method will
* remove password hash from shadow(4) file
(replace it with empty string)
* change root to normal account if it was configured
asa role.
7 Error handling
================
In case of success, smf unconfigure method will exit
with $SMF_EXIT_OK.
In case of fatal error, smf unconfigure method will exit
with$EXIT_ERR_FATAL error code. Following conditions will be
considered as fatal errors:
* CLI tools consumed for manipulating user and root account
(usermod(1M), userdel(1M)) fail.
* Failure when modifying SMF properties.
Reason of failure will be logged in smf log file
of svc:/system/config smf service.
8 Dependences
=============
* smf unconfigure framework
* userdel(1m)
9 Deliverables
==============
* unconfigure smf method for svc:/system/config smf service
* configured_user smf property for svc:/system/config smf service
10 Related documents
====================
[a]
http://hub.opensolaris.org/bin/view/Project+caiman/System+Configuration+Project
[b]
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/scsmfdesignlatest.pdf
[c]
http://src.opensolaris.org/source/xref/caiman/caiman-docs/sysconfig/sys-unconfig-design.odt
--
ORACLE ®
Glenn Faden| Senior Principal Software Engineer
Phone: +1 650 786 4003 | Mobile: +1 415 637 8181
OracleSolaris Security, Solaris Core OS Technology Engineering
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
--
ORACLE ®
Glenn Faden| Senior Principal Software Engineer
Phone: +1 650 786 4003 | Mobile: +1 415 637 8181
OracleSolaris Security, Solaris Core OS Technology Engineering
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
