date:20170202

zfs snapshot_limit is not respected

2017-02-02 Thread Ultima

I recently moved some data on a box with limited space. I decided I should
limit the snapshots so that space would not become an issue. I just check
back a week later to find out the box is hitting the borderline. Doing I
quick check I realized that the snapshot_limit is not being respected.

# uname -a
FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15 10:59:10
EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/MYKERNEL
 amd64

# zfs create zroot/bhyve/test
# zfs set snapshot_limit=0 zroot/bhyve/test
# zfs snapshot zroot/bhyve/test@1


# zfs snapshot zroot/bhyve/test@2
# zfs snapshot zroot/bhyve/test@3
# zfs list -t snapshot | grep zroot/bhyve/test
zroot/bhyve/test@1   0  -
 88K  -
zroot/bhyve/test@2   0  -
 88K  -
zroot/bhyve/test@3   0  -
 88K  -
# zfs get all zroot/bhyve/test | grep snapshot
zroot/bhyve/test  usedbysnapshots   0  -
zroot/bhyve/test  snapshot_limit0  local
zroot/bhyve/test  snapshot_count3  local

Also wanted to verify 0 was not being mistaken for none.

# for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk
'{print $1}'`; do zfs destroy $snapshot ; done

# zfs get all zroot/bhyve/test | grep snapshot
zroot/bhyve/test  usedbysnapshots   0  -
zroot/bhyve/test  snapshot_limit0  local
zroot/bhyve/test  snapshot_count0  local

# zfs set snapshot_limit=1 zroot/bhyve/test
# zfs snapshot zroot/bhyve/test@1
# zfs snapshot zroot/bhyve/test@2
# zfs snapshot zroot/bhyve/test@3
# zfs get all zroot/bhyve/test | grep snapshot
zroot/bhyve/test  usedbysnapshots   0  -
zroot/bhyve/test  snapshot_limit1  local
zroot/bhyve/test  snapshot_count3  local


Also tested on head
FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18
12:38:52 EST 2017
root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG
 amd64
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mlock and jail

2017-02-02 Thread Xin LI

On Thu, Feb 2, 2017 at 1:28 PM, Bruno Lauzé  wrote:
>
>
> But a simple user with no rights can mlock (64kb by default) why a jail would 
> not be able?
>

No, I'm not, by any means, arguing against having jailed processes
being able to mlock(), I'm just saying that we should have more fine
grained control over it (a knob to allow system administrators to
tweak it would be a good start).

Cheers,

>
> From: Xin LI
> Sent: Thursday, February 2, 2017 1:13 PM
> To: Pavel Timofeev
> Cc: Bruno Lauzé; 
> freebsd-current
> Subject: Re: mlock and jail
>
>
>
> On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev  wrote:
>> 2017-02-02 4:31 GMT+03:00 Xin LI :
>>> I like this idea.
>>>
>>> Note that potentially your patch would make it possible for a jailed
>>> root to DoS the whole system by locking too much of pages in memory.
>>> I think it would be sensible to provide a per-jail flag to enable
>>> doing it, or better, have some finer grained control (e.g. per jail
>>> quota of permitted locked pages).
>>>
>>> Why did the application want to lock pages in main memory, though?
>>
>> For example, this secret management tool
>> https://www.vaultproject.io/docs/config/ wants to lock memory for
>> security (surprise) reason.
>> It's available as security/vault in our ports tree.
>
> No it's not surprise but overkill IMHO.  Here is why:
>
> Locking memory does prevent swapping, but in a typical multi-user
> system, if an attacker is already able to read swap (keep in mind that
> disks are by default owned by root and can not be read in a typical
> setup), then the administrator already have much bigger problem to
> worry about, and the attacker would have much more powerful tools to
> steal the secrets.
>
> Additionally, if one really cares about safety of swap, they should
> have used encrypted swap in the first place.  On FreeBSD, appending
> '.eli' to the swap device in fstab (e.g. /dev/ada0p3 ->
> /dev/ada0p3.eli) would automatically do one-time keyed swapping.
>
> Moreover, I don't think it's a good idea to use an application that
> advocates locking all memory that it owns for "security" reasons: if
> the application writer does not know which memory pages would contain
> sensitive information, good chances that the application writer have
> no idea what is privilege separation and the design they have created
> could be fundamentally flawed.
>
> Cheers,
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: mlock and jail

2017-02-02 Thread Bruno Lauzé

But a simple user with no rights can mlock (64kb by default) why a jail would 
not be able?

From: Xin LI
Sent: Thursday, February 2, 2017 1:13 PM
To: Pavel Timofeev
Cc: Bruno Lauzé; 
freebsd-current
Subject: Re: mlock and jail

On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev  wrote:
> 2017-02-02 4:31 GMT+03:00 Xin LI :
>> I like this idea.
>>
>> Note that potentially your patch would make it possible for a jailed
>> root to DoS the whole system by locking too much of pages in memory.
>> I think it would be sensible to provide a per-jail flag to enable
>> doing it, or better, have some finer grained control (e.g. per jail
>> quota of permitted locked pages).
>>
>> Why did the application want to lock pages in main memory, though?
>
> For example, this secret management tool
> https://www.vaultproject.io/docs/config/ wants to lock memory for
> security (surprise) reason.
> It's available as security/vault in our ports tree.

No it's not surprise but overkill IMHO.  Here is why:

Locking memory does prevent swapping, but in a typical multi-user
system, if an attacker is already able to read swap (keep in mind that
disks are by default owned by root and can not be read in a typical
setup), then the administrator already have much bigger problem to
worry about, and the attacker would have much more powerful tools to
steal the secrets.

Additionally, if one really cares about safety of swap, they should
have used encrypted swap in the first place.  On FreeBSD, appending
'.eli' to the swap device in fstab (e.g. /dev/ada0p3 ->
/dev/ada0p3.eli) would automatically do one-time keyed swapping.

Moreover, I don't think it's a good idea to use an application that
advocates locking all memory that it owns for "security" reasons: if
the application writer does not know which memory pages would contain
sensitive information, good chances that the application writer have
no idea what is privilege separation and the design they have created
could be fundamentally flawed.

Cheers,
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

tcpdump broken on current and64

2017-02-02 Thread Manfred Antar

tcpdump breaks buildworld since it was updated yesterday. this is on 12.0 
Current amd64 r313099 kernel
Here is the error:

(tcpdump)5026}make
===> tcpdump (all)
/usr/local/bin/ccache cc  -O2 -pipe   -I/usr/src/usr.sbin/tcpdump/tcpdump 
-I/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump -DHAVE_CONFIG_H 
-D_U_="__attribute__((unused))" -DINET6 -DHAVE_OS_IPV6_SUPPORT -DLBL_ALIGN 
-I/usr/include/openssl -DHAVE_LIBCRYPTO -DHAVE_OPENSSL_EVP_H -DHAVE_NET_PFVAR_H 
-DHAVE_NET_IF_PFLOG_H -MD  -MF.depend.tcpdump.o -MTtcpdump.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef  -Qunused-arguments  -c 
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c -o 
tcpdump.o
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:41: 
warning: implicit declaration of function '_IOR' is invalid in C99 
[-Wimplicit-function-declaration]
static const unsigned long cmds[] = { BIOCGSTATS, BIOCROTZBUF };
  ^
/usr/include/net/bpf.h:128:20: note: expanded from macro 'BIOCGSTATS'
#define BIOCGSTATS  _IOR('B', 111, struct bpf_stat)
^
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:41: 
error: expected expression
/usr/include/net/bpf.h:128:35: note: expanded from macro 'BIOCGSTATS'
#define BIOCGSTATS  _IOR('B', 111, struct bpf_stat)
   ^
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:53: 
error: expected expression
static const unsigned long cmds[] = { BIOCGSTATS, BIOCROTZBUF };
  ^
/usr/include/net/bpf.h:145:36: note: expanded from macro 'BIOCROTZBUF'
#define BIOCROTZBUF _IOR('B', 128, struct bpf_zbuf)
   ^
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1934:13: 
error: invalid application of 'sizeof' to an incomplete type 'const unsigned 
long []'
sizeof(cmds) / sizeof(cmds[0])) < 0 && errno != ENOSYS) {
  ^~
1 warning and 3 errors generated.
*** Error code 1

Stop.
make[1]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump
*** Error code 1

Stop.
make: stopped in /usr/src/usr.sbin/tcpdump




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

tcpdump broken on current and64

2017-02-02 Thread Manfred Antar

tcpdump breaks buildworld since it was updated yesterday. this is on 12.0 
Current amd64 r313099 kernel
Here is the error:

(tcpdump)5026}make
===> tcpdump (all)
/usr/local/bin/ccache cc  -O2 -pipe   -I/usr/src/usr.sbin/tcpdump/tcpdump 
-I/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump -DHAVE_CONFIG_H 
-D_U_="__attribute__((unused))" -DINET6 -DHAVE_OS_IPV6_SUPPORT -DLBL_ALIGN 
-I/usr/include/openssl -DHAVE_LIBCRYPTO -DHAVE_OPENSSL_EVP_H -DHAVE_NET_PFVAR_H 
-DHAVE_NET_IF_PFLOG_H -MD  -MF.depend.tcpdump.o -MTtcpdump.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef  -Qunused-arguments  -c 
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c -o 
tcpdump.o
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:41: 
warning: implicit declaration of function '_IOR' is invalid in C99 
[-Wimplicit-function-declaration]
   static const unsigned long cmds[] = { BIOCGSTATS, BIOCROTZBUF };
 ^
/usr/include/net/bpf.h:128:20: note: expanded from macro 'BIOCGSTATS'
#define BIOCGSTATS  _IOR('B', 111, struct bpf_stat)
   ^
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:41: 
error: expected expression
/usr/include/net/bpf.h:128:35: note: expanded from macro 'BIOCGSTATS'
#define BIOCGSTATS  _IOR('B', 111, struct bpf_stat)
  ^
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:53: 
error: expected expression
   static const unsigned long cmds[] = { BIOCGSTATS, BIOCROTZBUF };
 ^
/usr/include/net/bpf.h:145:36: note: expanded from macro 'BIOCROTZBUF'
#define BIOCROTZBUF _IOR('B', 128, struct bpf_zbuf)
  ^
/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1934:13: 
error: invalid application of 'sizeof' to an incomplete type 'const unsigned 
long []'
   sizeof(cmds) / sizeof(cmds[0])) < 0 && errno != ENOSYS) {
 ^~
1 warning and 3 errors generated.
*** Error code 1

Stop.
make[1]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump
*** Error code 1

Stop.
make: stopped in /usr/src/usr.sbin/tcpdump

Looks like someone just fixed it !

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mlock and jail

2017-02-02 Thread Xin LI

On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev  wrote:
> 2017-02-02 4:31 GMT+03:00 Xin LI :
>> I like this idea.
>>
>> Note that potentially your patch would make it possible for a jailed
>> root to DoS the whole system by locking too much of pages in memory.
>> I think it would be sensible to provide a per-jail flag to enable
>> doing it, or better, have some finer grained control (e.g. per jail
>> quota of permitted locked pages).
>>
>> Why did the application want to lock pages in main memory, though?
>
> For example, this secret management tool
> https://www.vaultproject.io/docs/config/ wants to lock memory for
> security (surprise) reason.
> It's available as security/vault in our ports tree.

No it's not surprise but overkill IMHO.  Here is why:

Locking memory does prevent swapping, but in a typical multi-user
system, if an attacker is already able to read swap (keep in mind that
disks are by default owned by root and can not be read in a typical
setup), then the administrator already have much bigger problem to
worry about, and the attacker would have much more powerful tools to
steal the secrets.

Additionally, if one really cares about safety of swap, they should
have used encrypted swap in the first place.  On FreeBSD, appending
'.eli' to the swap device in fstab (e.g. /dev/ada0p3 ->
/dev/ada0p3.eli) would automatically do one-time keyed swapping.

Moreover, I don't think it's a good idea to use an application that
advocates locking all memory that it owns for "security" reasons: if
the application writer does not know which memory pages would contain
sensitive information, good chances that the application writer have
no idea what is privilege separation and the design they have created
could be fundamentally flawed.

Cheers,
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mlock and jail

2017-02-02 Thread Pavel Timofeev

2017-02-02 4:31 GMT+03:00 Xin LI :
> I like this idea.
>
> Note that potentially your patch would make it possible for a jailed
> root to DoS the whole system by locking too much of pages in memory.
> I think it would be sensible to provide a per-jail flag to enable
> doing it, or better, have some finer grained control (e.g. per jail
> quota of permitted locked pages).
>
> Why did the application want to lock pages in main memory, though?

For example, this secret management tool
https://www.vaultproject.io/docs/config/ wants to lock memory for
security (surprise) reason.
It's available as security/vault in our ports tree.

>
> On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauzé  wrote:
>>
>> I would like to ask if there is a reason I would have to applythe  patch 
>> below to make an application work in a jail.
>> And who's bad? the app too intrusive or the bsd not flexible enough 
>> (allow.mlock?)
>>
>>
>> Index: sys/kern/kern_jail.c
>> ===
>> --- sys/kern/kern_jail.c(revision 313033)
>> +++ sys/kern/kern_jail.c(working copy)
>> @@ -3340,6 +3340,11 @@
>> case PRIV_PROC_SETLOGINCLASS:
>> return (0);
>>
>>
>> +case PRIV_VM_MADV_PROTECT:
>> +case PRIV_VM_MLOCK:
>> +case PRIV_VM_MUNLOCK:
>> +return (0);
>> +
>> default:
>>
>>
>> ___
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mlock and jail (Elasticsearch/Java use case)

2017-02-02 Thread GomoR


Hello,

Giving mlock support to jails would also allow Elasticsearch 
(Java-based) to run as a jailed process.
In fact, Java can use a memory optimization trick for better 
performances by locking a specified amount of memory.


Thus, Elasticsearch has the need for such a setting to let it run at its 
full power.


Without this tunable, one cannot take advantage of this and 
Elasticsearch cannot run jailed to its full performance.
Furthermore, putting it outside of a jail is less confortable regarding 
overall system security.


Best regards,


On 2017-02-02 02:31, Xin LI wrote:

I like this idea.

Note that potentially your patch would make it possible for a jailed
root to DoS the whole system by locking too much of pages in memory.
I think it would be sensible to provide a per-jail flag to enable
doing it, or better, have some finer grained control (e.g. per jail
quota of permitted locked pages).

Why did the application want to lock pages in main memory, though?

On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauzé  wrote:


I would like to ask if there is a reason I would have to applythe  
patch below to make an application work in a jail.
And who's bad? the app too intrusive or the bsd not flexible enough 
(allow.mlock?)



Index: sys/kern/kern_jail.c
===
--- sys/kern/kern_jail.c(revision 313033)
+++ sys/kern/kern_jail.c(working copy)
@@ -3340,6 +3340,11 @@
case PRIV_PROC_SETLOGINCLASS:
return (0);


+case PRIV_VM_MADV_PROTECT:
+case PRIV_VM_MLOCK:
+case PRIV_VM_MUNLOCK:
+return (0);
+
default:


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

zfs snapshot_limit is not respected

Re: mlock and jail

RE: mlock and jail

tcpdump broken on current and64

tcpdump broken on current and64

Re: mlock and jail

Re: mlock and jail

Re: mlock and jail (Elasticsearch/Java use case)

8 matches

Site Navigation

Mail list logo

Footer information