On Mon, May 14, 2007 at 02:30:20PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm(a)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.
--
Axel.Thimm at
ATrpms.net