Tuesday June 14, 2005
Fixed 9 year old bug in usermod(1m). usermod: ERROR: username is in use. Cannot change it (for 9 years!)
I thought some people might find this small bug fix interesting now that OpenSolaris is open for business to all. It is in those class of things that really only get fixed because it anoys an engineer so much one day that they fix it. The problem with is one was this had been the behaviour since day one (SunOS 5.0) and the bug (1236941) was logged on 1996-02-02 and marked as an RFE. It had be evaulated in 1998-03-18 and marked as fix understood. Being an RFE and in a not very critical part of the code it just never got fixed.
I recently (2005-04-29) fixed it as a BUG, which is what it really was. The introduction of RBAC in Solaris 8 really pushed this from being midly anoying to a blatent bug, it mean I couldn't make root a role without editing /etc/user_attr directly. More importantly it meant I couldn't add profiles or authorisations to a role to give a user more access while they were logged in.
I fixed this because it was anoying users of my (currently internal but soon to appear externally) netprof package. In the postinstall of my package I ask for the username of the laptop primary user and attempt to use usermod(1M) to add the RBAC 'Network Administrator' profile to that account.
If the user was logged in and had su'd to root to add the package or had used pfexec pkgadd (with the Software Installation profile) and users couldn't use netprof out of the box. This resulting in so many emails over a period of a few months that I decided to fix usermod.
I actually did the fix on my laptop while in Tokyo giving the Solaris 10 TPT training. This is a nice simple case that shows how valuable the partial bringover feature of teamware can be sometimes all I needed in the workspace was $SRC/cmd/oamuser.
There are still some cases were we don't allow a change if the user is logged in. The following comment in usermod.c explains those cases:
/*
* We can't modify a logged in user if any of the following
* are being changed:
* uid (-u & -o), group (-g), home dir (-m), loginname (-l).
* If none of those are specified it is okay to go ahead
* some types of changes only take effect on next login, some
* like authorisations and profiles take effect instantly.
* One might think that -K type=role should require that the
* user not be logged in, however this would make it very
* difficult to make the root account a role using this command.
*/
The fix was really quite simple, it was really just making sure that we only
call isbusy()
when we were doing something that has critical impact the the account, for example
chaning its uid/gid or loginname. I'm now wondering if changing the home
dir should have been allowed, but for most people this is usually /home/
I need to check that smuser(1M) and smc(1M) don't have the same
problem. Those tools aren't yet in opensolaris.org since they aren't
in the ON consolidation but I expect they will arrive when the
ADMIN consolidation arrives in opensolaris.org.
If you are looking for crypto related code in OpenSolaris today you might be a little disapointed since not all of it is present yet. Let me assure you that we (me in particular) are working very hard to get it included. It is probably easiest to understand if I explain some history related to the Solaris source and what we intend to do about it so we can get you full access to the cryptographic frameworks and the algorithm implementations.
Even prior to the startup of the OpenSolaris program it was possible to get access to some of the source code of Solaris, how much you had to pay depended on what you intended to do with it and wither or not you were an academic instuition. Due to US export regulations all of the cryptographic algorithm implmentation and many cryptographic related plugin points into security frameworks had to have their interfaces obscured. This was because the source code was not open source and thus didn't get treated the same way as things like OpenSSL. If you were a domestic US customer it was possible to see the cryptographic algorithm implementations but still not some of the other things.
To achive this we put markers into many parts of the source to delimt things that needed to be removed, some times this was whole files, sometimes it was just
parts of functions. We then have a special run of the nightly build script that builds two different versions of the source product, one for domestic US (CRYPT_SRC build) and one for export (EXPORT_SRC build).
Technorati Tag: OpenSolaris
Technorati Tag: Solaris
OpenSolaris missing crypto code ?
Okay so how does this impact the crypto code ? Due to using the same mechanism to remove NDA code and code we previously couldn't release due to it being cryptographic source in a non open source licensed product we have a time consuming task of now unwinding these things. It is this thing that I and my colleagues are working on, we just didn't have enough time to complete this before today.
So whats the plan for getting access to the crypto code ? For the short term (read the next couple of days) we hope to get an additional download file put up that contains the missing cryptographic algorithm implementations and the missing bits of security frameworks (eg some bits of libgss and libsasl). For the longer term this code will be treated just like the rest of OpenSolaris visible source code and it will be browsable, buildable and downloadable just like usr/bin/ls and friends.
Technorati Tag: OpenSolaris
Technorati Tag: Solaris
This is a personal weblog, I do not speak for my employer.
