On 26.05.2014 17:31, Vladimir Sharun wrote:
Hello FreeBSD community,
Recently plays with securelevel and what I discover: no chance for
data to survive against remote root, except backups of course. Maybe
this log can be a proposal for raising securelevel further or include
securelevel
Hello,
if you have root privileges you can just write some random bytes in some
places and this will be enough to break your system. So, restricting
some gpart's or zpool's actions depending from securelevel looks like
protection from kids.
Having root under securelevel 3 confirmed disallows
On 29 May 2014, at 02:23, Bryan Drewery bdrew...@freebsd.org wrote:
As for skipping unneeded ports the best I can do is '-a' or Build it all.
If a port is only needed for WITH_X11 then an IGNORE should be added to it
when WITHOUT_X11 is set to prevent wasting time on it.
We can probably do a
On 29.05.2014 12:56, Vladimir Sharun wrote:
Hello,
if you have root privileges you can just write some random bytes in some
places and this will be enough to break your system. So, restricting
some gpart's or zpool's actions depending from securelevel looks like
protection from kids.
uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014 amd64
I'm also loading the Radeon_kms modules
Upon system startup, memory profile is clean. I get locked memory (mem_wire)
usage as:
9% before Radeon*.ko modules loaded
12% when slim is started (loads Radeon*.ko modules)
Hello,
Ok, you are right. But geom_dev restricts access only from user level
applications. When GEOM object does access directly via GEOM methods
this protection won't work. And it seems it isn't easy to fix, all
classes should have own check.
Thank you for better clarification. This is the
Are there any problems with MFC?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/newcons-and-beeping-X-tp5906883p5916170.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
freebsd-current@freebsd.org
TB --- 2014-05-29 11:00:39 - tinderbox 2.22 running on freebsd-current.sentex.ca
TB --- 2014-05-29 11:00:39 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE
FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB ---
On May 29, 2014, at 4:19, David Chisnall thera...@freebsd.org wrote:
On 29 May 2014, at 02:23, Bryan Drewery bdrew...@freebsd.org wrote:
As for skipping unneeded ports the best I can do is '-a' or Build it all.
If a port is only needed for WITH_X11 then an IGNORE should be added to it
On Mon, 12 May 2014 17:10:54 +0200
Claude Buisson clbuis...@orange.fr wrote:
On 05/12/2014 16:14, Aleksandr Rybalko wrote:
On Mon, 12 May 2014 15:35:48 +0200
Claude Buisson clbuis...@orange.fr wrote:
On 03/11/2014 15:27, Aleksandr Rybalko wrote:
Hello hackers!
Here is link to the
On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014 amd64
I'm also loading the Radeon_kms modules
Upon system startup, memory profile is clean. I get locked memory (mem_wire)
usage as:
9%before Radeon*.ko modules
On Thu, 29 May 2014 09:08:10 -0400
John Baldwin j...@freebsd.org wrote:
On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014
amd64 I'm also loading the Radeon_kms modules
SKIP
I don't know if the lsof dump in single
On 2014-05-29 08:42, Bryan Drewery wrote:
On May 29, 2014, at 4:19, David Chisnall thera...@freebsd.org wrote:
On 29 May 2014, at 02:23, Bryan Drewery bdrew...@freebsd.org wrote:
As for skipping unneeded ports the best I can do is '-a' or Build it all.
If a port is only needed for WITH_X11
On 2014-05-29 09:57, Alexander Kabaev wrote:
On Thu, 29 May 2014 09:08:10 -0400
John Baldwin j...@freebsd.org wrote:
On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014
amd64 I'm also loading the Radeon_kms modules
SKIP
Why do you think libc.so.7 has anything to do with this?
Well, because there are two instances of it running in the lsof dump, with
several possible child process candidates. Why would they be hanging
around when practically everything has been killed?
Radeon*.ko modules are a very strong
On 05/29/2014 15:17, Aleksandr Rybalko wrote:
On Mon, 12 May 2014 17:10:54 +0200
Claude Buisson clbuis...@orange.fr wrote:
On 05/12/2014 16:14, Aleksandr Rybalko wrote:
On Mon, 12 May 2014 15:35:48 +0200
Claude Buisson clbuis...@orange.fr wrote:
On 03/11/2014 15:27, Aleksandr Rybalko wrote:
On Thursday, May 29, 2014 9:57:22 am Alexander Kabaev wrote:
On Thu, 29 May 2014 09:08:10 -0400
John Baldwin j...@freebsd.org wrote:
On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014
amd64 I'm also loading the
On Thu, May 29, 2014 at 7:56 AM, Claude Buisson clbuis...@orange.fr wrote:
On 05/29/2014 15:17, Aleksandr Rybalko wrote:
On Mon, 12 May 2014 17:10:54 +0200
Claude Buisson clbuis...@orange.fr wrote:
On 05/12/2014 16:14, Aleksandr Rybalko wrote:
On Mon, 12 May 2014 15:35:48 +0200
Claude
On 2014-05-29 12:04, John Baldwin wrote:
On Thursday, May 29, 2014 9:57:22 am Alexander Kabaev wrote:
On Thu, 29 May 2014 09:08:10 -0400
John Baldwin j...@freebsd.org wrote:
On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote:
uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00
Hey all,
http://www.brendangregg.com/Perf/linuxperftools.png is a neat diagram.
Who wants to make one for FreeBSD? It'll even make its way to our
website documentation :)
--
Eitan Adler
___
freebsd-current@freebsd.org mailing list
On 28 May 2014 10:58, John Baldwin j...@freebsd.org wrote:
On Wednesday, May 28, 2014 1:51:28 pm Adrian Chadd wrote:
On 28 May 2014 06:56, John Baldwin j...@freebsd.org wrote:
Userland cpusets only default to 128 (CPU_MAXSIZE in sys/_cpuset.h).
Changing MAXCPU to even 128 is unfortunately
On Thursday, May 29, 2014 10:42:18 am Beeblebrox wrote:
Why do you think libc.so.7 has anything to do with this?
Well, because there are two instances of it running in the lsof dump, with
several possible child process candidates. Why would they be hanging
around when practically everything
On Thursday, May 29, 2014 12:53:54 pm Adrian Chadd wrote:
On 28 May 2014 10:58, John Baldwin j...@freebsd.org wrote:
On Wednesday, May 28, 2014 1:51:28 pm Adrian Chadd wrote:
On 28 May 2014 06:56, John Baldwin j...@freebsd.org wrote:
Userland cpusets only default to 128 (CPU_MAXSIZE in
On 29 May 2014 10:18, John Baldwin j...@freebsd.org wrote:
It costs wired memory to increase it for the kernel. The userland set size
can be increased rather arbitrarily, so we don't need to make it but so
large
as it is easy to bump later (even with a branch).
Well, what about making
On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
On 29 May 2014 10:18, John Baldwin j...@freebsd.org wrote:
It costs wired memory to increase it for the kernel. The userland set
size
can be increased rather arbitrarily, so we don't need to make it but so
large
as it is
On Thu, May 29, 2014 at 02:44:19PM -0400, John Baldwin wrote:
On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
On 29 May 2014 10:18, John Baldwin j...@freebsd.org wrote:
It costs wired memory to increase it for the kernel. The userland set
size
can be increased rather
On 29 May 2014 11:44, John Baldwin j...@freebsd.org wrote:
On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
On 29 May 2014 10:18, John Baldwin j...@freebsd.org wrote:
It costs wired memory to increase it for the kernel. The userland set
size
can be increased rather
On Thu, 29 May 2014 09:11:04 -0700
Kevin Oberman rkober...@gmail.com wrote:
On Thu, May 29, 2014 at 7:56 AM, Claude Buisson clbuis...@orange.fr
wrote:
On 05/29/2014 15:17, Aleksandr Rybalko wrote:
On Mon, 12 May 2014 17:10:54 +0200
Claude Buisson clbuis...@orange.fr wrote:
On
On Thursday, May 29, 2014 4:05:49 pm Adrian Chadd wrote:
On 29 May 2014 11:44, John Baldwin j...@freebsd.org wrote:
On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
On 29 May 2014 10:18, John Baldwin j...@freebsd.org wrote:
It costs wired memory to increase it for the kernel.
On Thursday, May 29, 2014 3:27:57 pm Konstantin Belousov wrote:
On Thu, May 29, 2014 at 02:44:19PM -0400, John Baldwin wrote:
On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
On 29 May 2014 10:18, John Baldwin j...@freebsd.org wrote:
It costs wired memory to increase it for
On 29 May 2014 13:18, John Baldwin j...@freebsd.org wrote:
anyway. Besides all of this - I'm thinking of just introducing:
typedef uint32_t cpuid_t;
.. then once we've converted all the users, we can make NOCPU
something other than 255 (which is the other limiting factor here..)
Any
On Thursday, May 29, 2014 5:09:05 pm Adrian Chadd wrote:
On 29 May 2014 13:18, John Baldwin j...@freebsd.org wrote:
anyway. Besides all of this - I'm thinking of just introducing:
typedef uint32_t cpuid_t;
.. then once we've converted all the users, we can make NOCPU
something other
On 29 May 2014 14:29, John Baldwin j...@freebsd.org wrote:
On Thursday, May 29, 2014 5:09:05 pm Adrian Chadd wrote:
On 29 May 2014 13:18, John Baldwin j...@freebsd.org wrote:
anyway. Besides all of this - I'm thinking of just introducing:
typedef uint32_t cpuid_t;
.. then once we've
On 29.05.2014 06:57, Fred Pedrisa wrote:
Hello,
There are 4 threads, and a total of 32 FDs. What do you think ?
-Mensagem original-
De: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Em nome de Adrian Chadd
Enviada em: quinta-feira, 29 de maio de
On Thu, May 29, 2014 at 4:20 PM, Allan Jude allanj...@freebsd.org wrote:
On 2014-05-29 08:42, Bryan Drewery wrote:
On May 29, 2014, at 4:19, David Chisnall thera...@freebsd.org wrote:
On 29 May 2014, at 02:23, Bryan Drewery bdrew...@freebsd.org wrote:
As for skipping unneeded ports
Ok.
Thanks for the enlightenment :)
-Mensagem original-
De: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp
Enviada em: quinta-feira, 29 de maio de 2014 18:55
Para: 'freebsd-current'
Assunto: Re: RES: KQueue vs Select (NetMap)
On
36 matches
Mail list logo
