On Mon, May 14, 2007 at 02:30:20PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@ATrpms.net) said:
Can we assume that the uid/gids < 100 were always considered sacred to the users, e.g. only to be set/modified by the vendor and not misused for local purposes? In other words, can we assume that these uid/gid are under the authority of the "setup" package?
Yes, absolutely.
If we can answer this with yes (which IMHO we should), then we can have "setup" upgrade passwd/group by removing all uid/gid < 100 in the files found on the system and insert its fresh ones. This would not only solve the issues at hand, but is an important mechanism to have in place for the "setup" package in general.
No, you can't. No prereqs allowed that early in the transaction.
prereqs? I was thinking more in the line of %post scripts that create a new passwd/group with the most current shipped uid/gid < 100 and save over the >= 100 uid/gids.
E.g. (untested)
# lock passwd/group file ... # create secure tmpfiles tmpfile_passwd=... ... # initialize with sacred uid/gid content cat /usr/share/setup/passwd > $tmpfile_passwd # filter out all uid < 100 from current passwd and save them over grep -v '^[^:]*:[^:]*:[0-9][0-9]?:' < /etc/passwd >> $tmpfile_passwd # can also use sort -n and sed ...similar with shadow/group/gshadow # cat $tmpfile_passwd > /etc/passwd rm -f $tmpfile_passwd ... # unlock passwd/group
That way we could always ensure that if users have installed/upgraded setup the sacred uid/gid space will be properly under our control.