[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2022-12-17 Thread Launchpad Bug Tracker
[Expired for libcap2 (Ubuntu) because there has been no activity for 60 days.] ** Changed in: libcap2 (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libcap2 in Ubuntu. https://bu

[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2022-10-18 Thread Serge Hallyn
> FWIW This used to be the default inside the libcap build tree, but the > problems with the container defaults (eventually fixed with > https://github.com/moby/moby/security/advisories/GHSA-2mm7-x5h6-5pvq Thanks for the links. For a moment I was worried that there was an issue with containers in

[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2022-10-06 Thread Dan Bungert
Yes, this appears to be deliberate upstream behavior and I'm not sure we should revert that. Marking incomplete, if there is further info please share. ** Tags removed: foundations-triage-discuss ** Changed in: libcap2 (Ubuntu) Status: New => Incomplete -- You received this bug notifica

[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2022-10-05 Thread Dan Bungert
** Tags added: foundations-triage-discuss -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libcap2 in Ubuntu. https://bugs.launchpad.net/bugs/1700814 Title: Default capability of cap_setfcap+i should be set on setcap Status

[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2022-10-04 Thread Balint Reczey
** Changed in: libcap2 (Ubuntu) Assignee: Balint Reczey (rbalint) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libcap2 in Ubuntu. https://bugs.launchpad.net/bugs/1700814 Title: Default capability of

[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2022-10-03 Thread Andrew G. Morgan
FWIW This used to be the default inside the libcap build tree, but the problems with the container defaults (eventually fixed with https://github.com/moby/moby/security/advisories/GHSA-2mm7-x5h6-5pvq ) changed my position on this: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id

[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2022-05-25 Thread Balint Reczey
@serge-hallyn I'm not sure why I got this bug assigned. :-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libcap2 in Ubuntu. https://bugs.launchpad.net/bugs/1700814 Title: Default capability of cap_setfcap+i should be set

[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2022-05-20 Thread Serge Hallyn
** Changed in: libcap2 (Ubuntu) Assignee: Serge Hallyn (serge-hallyn) => Balint Reczey (rbalint) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libcap2 in Ubuntu. https://bugs.launchpad.net/bugs/1700814 Title: Default

[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2018-02-26 Thread Serge Hallyn
Even unprivileged containers are now usable in containers with the right kernel, so this would be a good thing to add to the packaging. I'm not sure when I'll have time, but assigning to myself so that I can more easily find it when I do. ** Changed in: libcap2 (Ubuntu) Assignee: (unassigned

[Touch-packages] [Bug 1700814] Re: Default capability of cap_setfcap+i should be set on setcap

2017-06-29 Thread Serge Hallyn
Indeed it should be reasonable to do so. Note that there are cases, including unprivileged containers, where file capabilities cannot be set, so the packaging would have to gracefully handle (i.e. ignore) that failure rather than fail the package install. -- You received this bug notification be