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

Bug#799121: marked as done (local repository in non-world-readable directory doesn't work)

Your message dated Wed, 16 Sep 2015 15:02:42 +0200
with message-id <20150916130241.GA11156@crossbow>
and subject line Re: Bug#799121: local repository in non-world-readable directory doesn't work
has caused the Debian Bug report #799121,
regarding local repository in non-world-readable directory doesn't work
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
799121: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799121
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: apt
Version: 1.1~exp12

I'm using APT with a local repository configured with a file: URI. Also, the directory containing the repository is not world-readable. This works fine with APT 1.0, but not with APT 1.1.
I found that APT 1.1 runs some of its helper programs under a restricted _apt account, and they attempt to access repository files directly and fail. Specifically, when running `apt update`, debug logs indicate that `/usr/lib/apt/methods/xz` program attempts to access repository files and fails with EACCESS, probably as a result of running with limited privileges.

--- End Message ---
--- Begin Message --- 
On Wed, Sep 16, 2015 at 03:12:24AM +0300, Evgeny Kapun wrote:
> I'm using APT with a local repository configured with a file: URI. Also, the directory containing the repository is not world-readable. This works fine with APT 1.0, but not with APT 1.1.
> I found that APT 1.1 runs some of its helper programs under a restricted _apt account, and they attempt to access repository files directly and fail. Specifically, when running `apt update`, debug logs indicate that `/usr/lib/apt/methods/xz` program attempts to access repository files and fails with EACCESS, probably as a result of running with limited privileges.

That is about right. APT 1.1 is using _apt to perform actions like the
download of files or the uncompress of them instead of root – because
you usually don't need root rights for that and what is more important
bugs which (for example) would grant the attacker arbitrary code
execution do not give the attacker root rights this way.

You might say file:/ is local, so there is no attacker – but we can be
on a multi-user system. file:/ could also be located on a remote system
via NFS, sshfs or alike, which adds a transport vector 'invisible' to
apt, …

Surprisingly file:/ doesn't have the DropPrivsOrDie() call our other
methods have. An oversight I am going to correct for the reasons
mentioned above.

What is failing for you is indeed the uncompressor (its the same binary
for all uncompressors, just symlinked with different names) which
doesn't even know where the file we want it to uncompress came from
– could be http, could be file, …. While possible even through
complicated, it would probably be a very bad idea to try to detect it as
this attracts bugs and in the end the same reasons as for file:/ itself
apply.


You can disable this security feature via e.g. -o Debug::NoDropPrivs=1,
but a better idea is to just have the local repository "world-readable"
(or some other way of giving _apt permissions to read it) Anyone can
read the [copies of the] files in /var/lib/apt/lists anyway later on.
Or use the parsed data in the binary cache apt generates.


So, in short, this is a feature, not a bug. Closing therefore.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: