Bug 469275

A) We have to ask the user to confirm
B) I wasn't sure to put this in the UI or not -- what it's saying is:

You downloaded a file to a private location that can only be accessed by your user. As packagekitd runs under a different user (uid 0), we have to copy this file to /tmp (shared) so the daemon can access and install the file.

The reason it asks rather than just doing it, is that the rpm might be secure or private to the user, and probably shouldn't be put somewhere public without asking. This might be cracktastic, maybe we should just do it.

C) signatures are a necessary evil. Not that I like them either. :-(

>I think the installation failed

Normally when it fails it throws up a GUI error, but I admit I haven't handled the copy failed case. I'm slightly confused why it tries to copy to itself. Doing some debugging:

1. download file using firefox to /tmp
2. look at permissions:

-r-------- 1 hughsie hughsie 199960 2008-10-31 10:37 /tmp/codeblocks-devel-8.02-3.fc9.i386.rpm

So gnome-packagekit looks at the permissions for UID 0, and finds it's not able to access the file, so it chooses to copy the file to tmp and....

So, is the correct thing in this case:

1. firefox downloads the file with -r--r--r--?
2. gnome-packagekit chmod a+x the file before it does the uid 0 read check if the file is owned by the current user? Is this bad form making the file readable by all users?
3. change the copy directory to /tmp/packagekit rather than /tmp

Ideas welcome, but I'm erring on 3.

Richard.

As far as I know the installation did succeed despite the cp error (do you check the status?) "I think the installation failed" shows the problem with informally
narrating in the present tense :-).

The main reason for mentioning A) and C) was that the shear number of dialogs was dizzying... and after that many dialogs popping up, my expectation was definitely that it would continue to be chatty and give a dialog on success. 

The fact I was confused about whether it succeeded is not necessarily evidence
that there needs to be positive confirmation of success, it's just one data
point.

Of course, root can access -r--------- <somebody else> files fine.
(unless they are on a root-squashed nfs partition, AFS, etc.)

If you are really worried about root squash, then I'd suggest

 - Copy it to a mkstemp() file in /tmp with permissions -r-------
   (I assume packaging systems don't care about names) That will be
   readable by the user and root.
 - Don't ask me. Even if you have to make it world readable, don't ask
   me. Asking me doesn't make the security problem one whit better. 

I'm not sure I understand the a+x you propose. Do you mean a+r?

>Do you mean a+r?

Yes, sorry.

>Of course, root can access -r--------- <somebody else> files fine.

Except if they are using gvfs -- for instance look at bug https://bugzilla.redhat.com/show_bug.cgi?id=456094

You can reproduce mounting a ssh share using gfvs, and then trying to list files in /home/foo/.gvfs/ from the root user.

>Copy it to a mkstemp() file in /tmp

I thought about that too, but we hand yum a filename, not a fd, so there would be a race anyway. I'm thinking of just copying the file from $x to ~/.PackageKit/cache/ as then we don't have to use a world writeable directory like at all.

Of course, firefox is still ultimately downloading the file to /tmp and then executing the handler, so I'm sure that's not ideal either. Does firefox purposefully copy the file, or is that it's download-dir when it's going to launch a mime helper?

>Asking me doesn't make the security problem one whit better

No, sorry if it came out like that. I don't think this is any more of a security problem now as it was when we used pirut to install the package in F8, it's just not ideal at all. I'll work on the security copy check stuff now.

Richard.

Created attachment 322106 [details]
fixes permission and native confusion

This patch is a first cut at removing the permission checks, and relying on GIO to tell us if the file is native (i.e. not on FUSE filesystem). This fixes things for me.

The patch needs some more work, as that bit of code is horrible, and needs refactoring.

Richard.

commit 838241d093a7be7600d05d35d02b6e6050904b28
Author: Richard Hughes <richard>
Date:   Fri Oct 31 17:25:56 2008 +0000

    bugfix: fix the interaction when installing local files by only showing the
    copy dialog for non-native paths. Also add a confirm dialog when the files
    were installed correctly, and also make sure the dialog is shown for the
    untrusted 2nd pass of the installation. Fixes rh#469275

They'll be a new upstream release of PackageKit on Monday, although I probably
can't do a major version upgrade until we branch for F11.

Ohh, there are rpm's and srpm's here if you want to test: http://www.packagekit.org/packages/

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping