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

Bug#770388: apt-cache as a non-root user if a APT .list file is not readable



Hi David,

thank you for your thorough answer.

On Sun, Nov 23, 2014 at 03:20:26PM +0100, David Kalnischkies wrote:
> Hi Jonathan,
> 
> On Thu, Nov 20, 2014 at 10:35:40PM +0100, Jonathan Ballet wrote:
> > I tracked down the problem using strace and it seems that if a APT .list
> > file is not readable by a non-root user, apt-cache (in this case) goes
> > much, much slower:
> 
> Yes, but this isn't a bug. The sources.list tells us which repositories
> to get data from and by extension which files on disk contain this data.
> If the current user can't read the sources.list files, apt will not know
> which files are to be used and which ones are "stale". The binary cache
> it deploys to avoid reparsing all these files all the time will be
> considered invalid as it contains data from sources which (might or
> might not) be still in the unreadable sources.list file. The only reason
> we can be fast by using a binary cache is that we know that it is
> current – otherwise we would need to be a lot more careful while working
> with the data files which means we are a lot slower (as you
> experienced). So, this is all by design…
> 
> 
> In other words: If you want to use apt, the user you run it with needs
> read access to sources.list files. There is no point in forbidding read
> access here anyway as you /can/ force apt to consider the binary cache
> as valid and hence extract the data or lookup the filenames in the lists
> directory or or or.

I understand this design decision, my "use-case" was more like: I
created a sources.list file with the wrong permission, and my normal
user couldn't read it. As such, running apt-cache without being root
was much, much slower. As I usually never use apt-cache as root and that
nothing reports that this file can't be read and that apt-cache is going
to use this slower codepath, I thought there was a much more serious
problem on my machine than just this file permission issue.

In the end, I had to resort to strace to discover the real underlying
problem, which is not really intuitive although 1. this situation is
kind of abnormal (I understand what you said this way) and 2. the fix is
really simple.

Is there a way this issue could have been avoided?

Best regards,

 Jonathan


Reply to: