Jan Parcel wrote: > >> Note that this means that the workaround suggested in the bug report is a >> poor one, because it has the same non-atomic behavior. >> > > Actually it is a pretty good workaround if combined with: > > 1. Doing the copy very frequently > 2. Basing the decision to copy upon diffs rather than date. > 3. removing /usr/bin/passwd in the labeled zones > > The reason: > > The global zone's passwd file's atomic safety is being preserved using the > original rules and the global zone is using that passwd file. > > The only things that get these unsafe copy operations are COPIES. If > the global zone's passwd file is still good, then you can still log into > TJDS or TCDE and you can still log into the global zone via the console > (if enabled) -- so you can still get in to fix things. In addition, > if the copy is set to run once every minute or two, any one bad copy > will only last a minute or two, if the decision to copy is based > upon diffs rather than on "-newer" logic. > I don't understand the advantage of diff vs. -newer. The latter is simpler so why not use it? My suggested workaround also deals with the case where the copy doesn't exist yet.
As you've noted, the /etc/shadow file in the labeled zones is not used by the desktop software. Just for remote login, e.g. ssh. So, while not a perfect workaround, it is likely to satisfy the customer. Ultimately the customer should be using ldap to keep passwords in sync. --Glenn > The reason for removing /usr/bin/passwd from the labeled zones is that > it operates on the local end, instead of the global zone shadow file, so > any changes get overmounted or discarded or something next zone reboot. > > (I have been unable to check the exact mechanism here because shutting down > the zones does not appear to umount passwd and shadow.) > > > >> -- Jeff >> _______________________________________________ >> security-discuss mailing list >> security-discuss at opensolaris.org >> > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > Jan Parcel, Sustaining, Trusted OE > > > _______________________________________________ > security-discuss mailing list > security-discuss at opensolaris.org >
