On Thu, Feb 02, 2017 at 09:30:58PM +0100, Bennett Piater wrote:
> On 02/02/2017 07:28 PM, Leonid Isaev wrote:
> > I already described an approach when one always runs browsers, pdf readers,
> > etc, inside an lxc container, as an unprivileged user. That container
> > resides
> > on a filesystem mo
On Fri, 3 Feb 2017 02:37:53 +0200, Pekka Järvinen wrote:
>I would suggest mentioning this manual compiling to the wiki page
Hi,
IMO using a PKGBUILD from ABS and changing options by the PKGBUILD or a
config is the easiest way to go. Compiling without building a package
could lead to issues. Could
Hi,
2017-02-02 21:43 GMT+02:00 Neven Sajko via arch-general <
arch-general@archlinux.org>:
> Since you are a beginner, maybe it would have been better to first
> just compile lxrandr manually, instead of with makepkg.
>
This finally provided results!
main (argc=, argv=) at lxrandr.c:783
783
Guus Snijders via arch-general writes:
> Op 2 feb. 2017 20:58 schreef "Thorsten Jolitz via arch-general" <
> In the first case, perhaps a tunnel provider can help as your current setup
> appears flaky at best. In the second case, it's probably better to find out
> how to disable IPv6 on your mac
Op 2 feb. 2017 20:58 schreef "Thorsten Jolitz via arch-general" <
arch-general@archlinux.org>:
Robin via arch-general writes:
>> - IPv6 is tried , but takes forever and has 100% package loss
>> (frecuent).
>> - pinging IPv6 addresses works (very rare)
[...]
that explains it very well. ping
On 02/02/2017 10:29 AM, sivmu wrote:
> Am 02.02.2017 um 11:28 schrieb Daniel Micay via arch-general:
>> On Thu, 2017-02-02 at 02:40 +0100, sivmu wrote:
>>> Am 01.02.2017 um 21:21 schrieb Daniel Micay via arch-general:
>> it's a nearly useless feature.
>
> That's a baseless claim, that
On 02/02/2017 07:28 PM, Leonid Isaev wrote:
> I already described an approach when one always runs browsers, pdf readers,
> etc, inside an lxc container, as an unprivileged user. That container resides
> on a filesystem mounted with nosuid (so things like ping, su, sudo won't
> work),
> and has a
Robin via arch-general writes:
>> - IPv6 is tried , but takes forever and has 100% package loss
>> (frecuent).
>> - pinging IPv6 addresses works (very rare)
> That's strange. A traceroute with booth working v6 and not working v6
> would be helpful. Also a output of your routing table would be
After glimpsing through your makepkg and PKGBUILD:
Are you sure you are using makepkg-debug.conf instead of makepkg.conf
as the config?
Since you are a beginner, maybe it would have been better to first
just compile lxrandr manually, instead of with makepkg.
BTW, maybe arandr would suffice as a replacement for lxrandr?
A few notes:
You can use, eg., the file command to check if executables are stripped.
(with something like "file /bin/executable")
But gdb already tells you that no debugging symbols were found for the
executable.
Thus, you either need install an lxrandr package with debugging
symbols (with -g an
Op 2 feb. 2017 16:06 schreef "Francisco Barbee via arch-general" <
arch-general@archlinux.org>:
So what's your alternatives/setup usable on Arch
(not android, not ChromeOS)? We heave disabled
SElinux, disabled Apparmor, disabled user
namespaces, PIE not enabled by default and only
partial relro.
Am 02.02.2017 um 19:28 schrieb Leonid Isaev:
> On Thu, Feb 02, 2017 at 03:24:11AM +0100, sivmu wrote:
>> Please take a look at bubblewrap
>> https://github.com/projectatomic/bubblewrap
>> On the default arch kernel it does not use user namespaces.
>
> And? Why do you point out such projects?
>
> - IPv6 is tried , but takes forever and has 100% package loss
> (frecuent).
> - pinging IPv6 addresses works (very rare)
That's strange. A traceroute with booth working v6 and not working v6 would be
helpful. Also a output of your routing table would be nice.
> - pinging pure IPv6 addresse
On Thu, 2017-02-02 at 19:32 +0200, Francisco Barbee wrote:
>
> So your advice for now would be to use grsecurity
> kernel and forget all those jails and namespaces
> until someone figure out proper security solution?
No, the advice is to learn what you are trying to defend against, instead of
was
On Thu, 2017-02-02 at 19:32 +0200, Francisco Barbee wrote:
>
> So your advice for now would be to use grsecurity
> kernel and forget all those jails and namespaces
> until someone figure out proper security solution?
I never said that...
It simply doesn't make sense to base application sandboxes
On Thu, Feb 02, 2017 at 03:24:11AM +0100, sivmu wrote:
> Am 01.02.2017 um 21:16 schrieb Leonid Isaev:
> >
> > But you see, sandboxing apps is by itself is a misleading security feature.
> > Why do I need to sandbox my browser if it is written properly and allows me
> > to disable the unnecessary (
Damjan Georgievski via arch-general writes:
>> And the most surprising thing is, that it worked for one single moment,
>> see the PS, and stopped working after the next reboot - with all what I
>> tried to make it work still untouched and in place.
>>
>> Any further tipps here?
>
> do you even ha
Am 02.02.2017 um 17:45 schrieb Daniel Micay via arch-general:
> SubgraphOS doesn't use user namespaces.
It also is not a lightweight solution that compares to the tools in
question for that matter. But I get your point.
>> I was under the impression that all
>> namespaces were enabled by defau
- Reply to message -
Subject: Re: [arch-general] user namespaces
Date: 2 February 2017 at 18:22:36
From: "Daniel Micay"
To: "General Discussion about Arch Linux"
:
> On Thu, 2017-02-02 at 17:06 +0200, Francisco
Barbee via arch-general
> wrote:
>> So what's your alternatives/setup usable o
On Thu, 02 Feb 2017 11:49:38 -0500, Daniel Micay via arch-general wrote:
>On Thu, 2017-02-02 at 17:39 +0100, Ralf Mardorf wrote:
>> On Thu, 02 Feb 2017 11:22:28 -0500, Daniel Micay via arch-general
>> wrote:
>> > The reason for SELinux and AppArmor not being enabled for linux or
>> > linux-grsec
On Thu, 2017-02-02 at 17:39 +0100, Ralf Mardorf wrote:
> On Thu, 02 Feb 2017 11:22:28 -0500, Daniel Micay via arch-general
> wrote:
> > The reason for SELinux and AppArmor not being enabled for linux or
> > linux-grsec has to do with audit. If people were willing to do a bit
> > of work, all of the
On Thu, 2017-02-02 at 16:29 +0100, sivmu wrote:
>
> Am 02.02.2017 um 11:28 schrieb Daniel Micay via arch-general:
> > On Thu, 2017-02-02 at 02:40 +0100, sivmu wrote:
> > >
> > > Am 01.02.2017 um 21:21 schrieb Daniel Micay via arch-general:
> > > > > > it's a nearly useless feature.
> > > > >
>
On Thu, 02 Feb 2017 11:22:28 -0500, Daniel Micay via arch-general wrote:
>The reason for SELinux and AppArmor not being enabled for linux or
>linux-grsec has to do with audit. If people were willing to do a bit
>of work, all of the MAC implementations rather than only grsecurity
>RBAC and TOMOYO co
On Thu, 2017-02-02 at 17:06 +0200, Francisco Barbee via arch-general
wrote:
> So what's your alternatives/setup usable on Arch
> (not android, not ChromeOS)? We heave disabled
> SElinux, disabled Apparmor, disabled user
> namespaces, PIE not enabled by default and only
> partial relro. What's left
On Thu, 2 Feb 2017 16:29:52 +0100, sivmu wrote:
>Is there any chance to get the arch main kernel to use such a patch for
>privileged user namespaces like with grsec?
Hi,
you could provide the kernel by the AUR and see how many votes it gets.
Note "linux-grsec" is provided by "Community" and "linu
Am 02.02.2017 um 11:28 schrieb Daniel Micay via arch-general:
> On Thu, 2017-02-02 at 02:40 +0100, sivmu wrote:
>>
>> Am 01.02.2017 um 21:21 schrieb Daniel Micay via arch-general:
> it's a nearly useless feature.
That's a baseless claim, that was already proved wrong in my first
>>
So what's your alternatives/setup usable on Arch
(not android, not ChromeOS)? We heave disabled
SElinux, disabled Apparmor, disabled user
namespaces, PIE not enabled by default and only
partial relro. What's left then? Swimming naked?
Hi,
This will only build the package. Make sure to install it, or use
> 'makepkg -sfi' to install it automatically.
>
% makepkg -sfi
...
loading packages...
warning: lxrandr-0.3.1-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
error: unresolvable pac
Am 02.02.2017 um 09:51 schrieb Ralf Mardorf:
On Thu, 2 Feb 2017 07:34:27 +0100, Peter Nabbefeld wrote:
after editing .SRCINFO to reflect the correct version
id.
Others already pointed out that you don't need this file to build a
package at all, apart from this you don't need to edit this file,
> I've installed ABS, modified PKGBUILD and made my own /etc/makepkg-dev.conf
No need to change both makepkg.conf and the PKGBUILD. Either will do.
> makepkg -sf --config /etc/makepkg-dev.conf generates the executable.
This will only build the package. Make sure to install it, or use
'makepkg -s
On Thu, 2017-02-02 at 02:40 +0100, sivmu wrote:
>
> Am 01.02.2017 um 21:21 schrieb Daniel Micay via arch-general:
> > > > it's a nearly useless feature.
> > >
> > > That's a baseless claim, that was already proved wrong in my first
> > > post
> > > by the many applications that use this feature.
On Thu, 2 Feb 2017 07:34:27 +0100, Peter Nabbefeld wrote:
>after editing .SRCINFO to reflect the correct version
>id.
Others already pointed out that you don't need this file to build a
package at all, apart from this you don't need to edit this file, simply
generate one:
"makepkg --printsrcinfo
On Wed, 1 Feb 2017 13:16:12 -0700, Leonid Isaev wrote:
>So, why don't you just build your own kernel? It takes only 20 mins...
I agree that users should build the kernel on their own, if they want
special features, but on many old machines it takes much longer to build
a kernel based on a default
34 matches
Mail list logo