Date: Sun, 09 Aug 1998 09:23:54 -0700 From: User GregGreg Shenaut <greg@bogslab.ucdavis.edu> To: questions@FreeBSD.ORG Subject: global reassignment of uid/gid Message-ID: <199808091624.JAA04603@deal1.bogs.org>
next in thread | raw e-mail | index | archive | help
I am moving from a bsd/os environment to a freebsd one. Most things
are moving along smoothly, but it seems that the two environments
differ in their assignment of userids and groupids.
The userids for bsdos tend to start at 100 for ordinary users; for
freebds they start at 1000. I like the 1000 starting point better,
in fact, but there is still the problem of globally changing all
of the userids on every file on every system. Also, what about
backups? I use mostly tar, some dumps: is there any known way of
supplying a reassignment table which can be used to "map" old
userids to new ones as part of the restore process?
The problem with groupids is more complicated. The groupids for
ordinary users have the same difference of starting at 100 for
bsdos and at 1000 for freebsd, but there is another difference as
well: under bsdos, ordinary users are generally assigned to one a
a small number of groups ("user", "staff", and so on) while under
freebsd, each user is assigned a unique groupid, generally the same
as the userid, and each shared project or other shared domain is
assigned a pseudo-userid. Under the bsdos system, then, most users'
files tend to have the same groupid, so group write permission is
usually off. However, since under the freebsd system, each user's
files have a unique groupid, group write permission tends to be
on. Before I came to bsdos I had used a system similar to the
freebsd one, so I have no problem moving back to it, but not only
do all of the groupids have to be reassigned, but also the permissions
have to be altered for certain userid.groupid pairs.
Finally, since the userids and groupids are independent under bsdos,
when files need to be shared, you just have to create a new group
which includes all of the users who need to work on them, and make
the directory containing the shared files owned by that group, with
group write permission turned on. Under freebsd, you create a new
userid.groupid entity with no login permissions, add the members
of the team to the group, and have the directories owned either by
the project's userid.groupid or by one of the members, with the
project's groupid.
Therefore, in any set of files that need to be brought into freebsd
from bsdos, there will need to be a set of conditional changes of
userid, groupid, and group permissions. I have done this kind of
thing in the past using kludges of one sort or another, including
a hack which I no longer can even find that filtered a tar format
data stream to change userids and groupids on an archive before it
got to tar. I don't think the old program would work even if I
had it, because it only used Version 7 format tar files--an up-to-date
program would need to know several other formats. Another method
I've used is find scripts, but these are very dangerous if the set
of "from" userid/groupid/permissions overlaps with the "to" values:
what do you do if the process is interrupted before it is completed
in this case?
It seems to me that the best way to do this kind of thing would be
to hack tar itself to consult a mapping table immediately before
it sets each file's ownership and modes during restores. The
format for the mapping would be nontrivial, although I suppose
it might not be too difficult to have tar itself construct a
database of all of the combinations of userid groupid and group
permissions in an archive: this could then be edited to create
a mapping database.
Any ideas?
-Greg
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808091624.JAA04603>