From owner-freebsd-questions Sun Aug 9 09:26:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA00150 for freebsd-questions-outgoing; Sun, 9 Aug 1998 09:26:03 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from bogslab.ucdavis.edu (bogslab.ucdavis.edu [128.120.162.26]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA00106 for ; Sun, 9 Aug 1998 09:25:57 -0700 (PDT) (envelope-from greg@bogslab.ucdavis.edu) Received: from deal1.bogs.org (deal1.bogs.org [198.137.203.51]) by bogslab.ucdavis.edu (8.7.4/8.7.3) with ESMTP id JAA08052 for ; Sun, 9 Aug 1998 09:25:33 -0700 (PDT) Received: from deal1.bogs.org (localhost [127.0.0.1]) by deal1.bogs.org (8.8.8/8.6.12) with ESMTP id JAA04603 for ; Sun, 9 Aug 1998 09:24:00 -0700 (PDT) Message-Id: <199808091624.JAA04603@deal1.bogs.org> To: questions@FreeBSD.ORG Subject: global reassignment of uid/gid Reply-To: gkshenaut@ucdavis.edu Date: Sun, 09 Aug 1998 09:23:54 -0700 From: User GregGreg Shenaut Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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