[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Fedora-packaging] Re: Second user/group handling draft



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.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpmwUgoCmqBB.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]