On Mon, Jul 01, 2019 at 02:47:08PM +0200, Michael Schaller wrote:
> Looks like there is no reply from the Apt maintainers. Should I open a
> bug against apt?
The _apt user is used in stable, and various Ubuntu LTS, and so far,
nobody cared about us creating it dynamically. So this is not a matter
Hi all,
Quoting Philipp Kern (2019-06-23 15:14:34)
> On 2019-06-21 07:51, Trek wrote:
> >> If _apt deserves a special solution, I would suggest assigning the
> >> _apt user a static uid instead of patching debootstrap.
> > it seems to me the simplest approach, from a technical point of view,
> >
On 2019-06-21 07:51, Trek wrote:
On Thu, 20 Jun 2019 22:31:15 +0200
Ansgar Burchardt wrote:
If _apt deserves a special solution, I would suggest assigning the
_apt user a static uid instead of patching debootstrap.
it seems to me the simplest approach, from a technical point of view,
and
On 2019-06-21 20:36, Ben Hutchings wrote:
On Thu, 2019-06-20 at 20:33 +0200, Philipp Kern wrote:
On 20/06/2019 09:50, Ansgar Burchardt wrote:
> Ansgar Burchardt writes:
> > (I don't maintain debootstrap.)
> >
> > I don't think it is a good idea to require debootstrap to know about
> > such
On Thu, 2019-06-20 at 20:33 +0200, Philipp Kern wrote:
> On 20/06/2019 09:50, Ansgar Burchardt wrote:
> > Ansgar Burchardt writes:
> > > (I don't maintain debootstrap.)
> > >
> > > I don't think it is a good idea to require debootstrap to know about
> > > such details.
> > >
> > > For limiting
On Thu, 20 Jun 2019 22:31:15 +0200
Ansgar Burchardt wrote:
> If _apt deserves a special solution, I would suggest assigning the
> _apt user a static uid instead of patching debootstrap.
it seems to me the simplest approach, from a technical point of view,
and it's the one I'm using since _apt
Philipp Kern writes:
> 20/06/2019 20:22, Ansgar Burchardt wrote:
>> You look up which uid the _apt user inside the chroot has and use that.
>
> Yeah, but that scales poorly if you have a centralized firewall
> policy. It means that you need to maintain dynamic rules. I know it's
> possible and you
On 20/06/2019 09:50, Ansgar Burchardt wrote:
Ansgar Burchardt writes:
(I don't maintain debootstrap.)
I don't think it is a good idea to require debootstrap to know about
such details.
For limiting network access, I would recommend instead using network
namespaces (to only provide limited
On 20/06/2019 20:22, Ansgar Burchardt wrote:
Trek writes:
Ansgar Burchardt wrote:
For limiting network access, I would recommend instead using network
namespaces (to only provide limited network access for all processes)
and/or user namespaces (if filtering for single UIDs is really
needed).
Trek writes:
> Ansgar Burchardt wrote:
>> For limiting network access, I would recommend instead using network
>> namespaces (to only provide limited network access for all processes)
>> and/or user namespaces (if filtering for single UIDs is really
>> needed). These do not require any uids to
On Thu, 20 Jun 2019 09:32:17 +0200
Ansgar Burchardt wrote:
> I don't think it is a good idea to require debootstrap to know about
> such details.
_apt user is standard to debian, but not its uid
the _apt user is created by the apt postinst, that cannot know anything
about the host system from
Ansgar Burchardt writes:
> (I don't maintain debootstrap.)
>
> I don't think it is a good idea to require debootstrap to know about
> such details.
>
> For limiting network access, I would recommend instead using network
> namespaces (to only provide limited network access for all processes)
>
Michael Schaller writes:
> At the end of the 'apt' package installation the '_apt' user will be
> created without specifying a fixed uid. This typically results in a
> differing '_apt' uid between the host system and the bootstrapped
> system. The differing '_apt' uid is problematic in case the
Patch proposal:
https://salsa.debian.org/installer-team/debootstrap/merge_requests/32
Patch note: This patch introduces the 'setup_users_groups' function
which is inspired by the existing 'setup_dselect_method' function.
14 matches
Mail list logo
