On Mon, Nov 16, 2015 at 09:00:28PM +0100, Damjan Georgievski wrote:
> >> What's the policy about capabilities for executables in Arch packages?
> >
> > I _guess_ that capabilities are used to avoid SUID binaries when this is
> > secure.
>
> well, also, unless you set capabilities on the executable
>> What's the policy about capabilities for executables in Arch packages?
>
> I _guess_ that capabilities are used to avoid SUID binaries when this is
> secure.
well, also, unless you set capabilities on the executable a process
can't have capabilities when a non-root process execs the executable
On Mon, Nov 16, 2015 at 07:51:30PM +0100, Damjan Georgievski wrote:
> What's the policy about capabilities for executables in Arch packages?
I _guess_ that capabilities are used to avoid SUID binaries when this is
secure.
> I'm asking since in my setup I'm running wpa_supplicant as the
> 'nobody'
What's the policy about capabilities for executables in Arch packages?
I'm asking since in my setup I'm running wpa_supplicant as the
'nobody' user, but I let it keep the NET_ADMIN and NET_RAW
capabilities (excerpt from the .service file):
User=nobody
SupplementaryGroups=rfkill
CapabilityBounding
Doug Newgard wrote:
> On Mon, 16 Nov 2015 00:38:04 -0500 (EST)
> Scott Lawrence wrote:
>>
>> Is there an intention to update this package straight to 2.1, or to
>> introduce a gsl2 package? I've no problem with putting this on AUR
>> myself, but I don't want to step on toes / waste time.
>>
>
>On Sun, 15 Nov 2015, Doug Newgard wrote:
>> Putting it in the AUR would just get it deleted. Rule 1 of the AUR
>> is that it can't duplicate packages in the official repos.
The OP could provide gsl-git by the AUR ;).
On Mon, Nov 16, 2015 at 3:17 PM, Magnus Therning wrote:
> On Sun, Nov 15, 2015 at 11:31:27AM -0600, Doug Newgard wrote:
>> On Sun, 15 Nov 2015 17:56:30 +0100
>> Magnus Therning wrote:
>>
>> > I've just updated a sligtly neglected machine I have (not upgraded
>> > since mid-September). Thanks to t
7 matches
Mail list logo