On Sep 16, 2017, at 04:57, db wrote:
> On 15 Sep 2017, at 23:47, Ryan Schmidt wrote:
>> MacPorts and ports can add users, but MacPorts doesn't remove them. I'm not 
>> sure how we could change that. Suppose you install a port that has a user 
>> that needs to own some data, such as postresql96-server. You then uninstall 
>> the port, which then hypothetically removes the user. Now the databases you 
>> created with that port are owned by a userid that doesn't exist anymore. Now 
>> you reinstall the port, which creates a postgres user but with a new userid. 
>> This creates more work for the user: needing to reassociate files the port 
>> needs with the new userid.
> 
> Shouldn't MP delete it if no files are owned by that user? In any case, it 
> could notify during installation that a user was created and upon 
> uninstallation that a user still owns files (and which) or not, and if not, 
> it could give the option to delete it.

Maybe. But how would MacPorts know that no files are owned by that user? I 
wouldn't want a port uninstallation to introduce a several-minute delay while 
MacPorts checks the ownership of every file on disk. And as you found below, 
you may have unexpected files owned by such a user.


> I searched for files owned by users created by two ports installed not long 
> ago (quagga is still installed, dbus uninstalled) to find the following (just 
> an example of a mess I now realised it's in place and I don't have a clue how 
> it happened).
> 
> $ ls -l /Library/Screen\ Savers/Substrate.saver/Contents
> total 16
> -rw-r--r--@ 1 root    messagebus   692 Apr 12  2010 CodeResources
> -rw-r--r--@ 1 root    messagebus  1491 Apr 12  2010 Info.plist
> drwxr-xr-x@ 3 quagga  messagebus   102 Apr 12  2010 MacOS
> drwxr-xr-x@ 3 quagga  messagebus   102 Apr 12  2010 Resources
> drwxr-xr-x@ 3 quagga  messagebus   102 Apr 12  2010 _CodeSignature
> 
> AFAIR, I installed that screen saver by dragging and dropping, no installer.

This is probably normal.

When a user is created on Mac OS X 10.5 Leopard and later, its group is set to 
"staff". But on Mac OS X Tiger 10.4 and earlier, each user got a group of its 
own, named the same as the user.

File ownership can be preserved on disk images, but that ownership is preserved 
by uid and gid, not by user name and group name.

Suppose that the person who packed up Substrate.saver was on a Mac running 
Tiger with two user accounts, one with uid 501 (alice) and gid 501 (alice) and 
another with uid 502 (bob) and gid 502 (bob), and that the person was logged in 
as bob. This person compiles Substrate.saver, which causes it to be owned by 
uid/gid 502, then creates a disk image with ownership preserved, and copies the 
screensaver bundle to the disk image and uploads the disk image to the 
Internet, where you download it.

You're on a Mac with Leopard or later and you only have one user account, with 
uid 501 and gid 20 (staff). You copy the screensaver from the disk image to 
your disk, and ownership is preserved. If you look at the ownership of the 
screensaver now with ls -l, you'll see it's owned by uid 502 and gid 502, even 
though you don't have a user nor a group with those ids.

Later you install the dbus and quagga ports. They each create their own user 
accounts, using whatever uids and gids are unused on your system. They may not 
be the same. For example on my system my messagebus user has uid 500 but my 
messagebus group has gid 504. On your system, the quagga user happened to get 
uid 502 and the messagebus group happened to get gid 502. When you now look 
with ls -l, you see that the screensaver is owned by user quagga and group 
messagebus.

It wouldn't matter if the order was reversed--if you installed the ports and 
MacPorts created the users and groups first, and then you copied the 
screensaver--the end result would be the same.

The problem should not have occurred if the disk image was set not to preserve 
ownership. In that case, when you copied the file from the disk image to your 
disk, it would have received the user and group of your user.

You can also run into this type of problem if you have multiple Macs that you 
copy files between while preserving ownership, such as using a USB or FireWire 
disk with owners turned on, or by using Apple file sharing, and the user 
accounts on the different Macs are not all using the same uid/gid.


> MP could also checked if the UIDs/GIDs are already in use, before a port 
> creates a user/group.

MacPorts already does this, in that the MacPorts command to create a new user 
will use the first uid numbered 500 or greater that does not already exist in 
the directory service. Or did you mean something different by "already in use"?


Reply via email to