similar to: GELI improvements.

Hi. geli(8) from FreeBSD-CURRENT is now able to perform data integrity verification (data authentication) using one of the following algorithms: - HMAC/MD5 - HMAC/SHA1 - HMAC/RIPEMD160 - HMAC/SHA256 - HMAC/SHA384 - HMAC/SHA512 One of the main design goals was to make it reliable and resistant to power failures or system crashes. This was very important to commit both data update and HMAC

? 2007-3-15???8:00?freebsd-security-request@freebsd.org ??? > Send freebsd-security mailing list submissions to > freebsd-security@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-security > or, via email, send a message with subject or body 'help' to > freebsd-security-request@freebsd.org

Hi. I gave a talk about ZFS during EuroBSDCon 2007, and because it won the the best talk award and some find it funny, here it is: http://youtube.com/watch?v=o3TGM0T1CvE a bit better version is here: http://people.freebsd.org/~pjd/misc/zfs/zfs-man.swf BTW. Inspired by ZFS demos from OpenSolaris page I created few demos of ZFS on FreeBSD:

Hi. I'd like to commit this patch: http://people.freebsd.org/~pjd/patches/vfs_mount.c.9.patch It currently should change nothing, but will be needed once we allow to grant privileges for jails. I'd like to commit it now, so I can experiment easier with my ZFS improvements. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org

Hello, I was playing around with geli an gbde after last EuroBSDCon. I liked the idea of encrypting my data which resides in /home/$user. Since this is a "single" user laptop i intended to encrypt the whole /home partition. Well no problems with that. But i wanted the lockfile or keyfile on a seperate usb disc. Which would be mounted or used during boot of the system. I also used

Hello, FYI: A FreeBSD user suggested that this issue requires a security advisory. The issue has been public for some time, but currently, FreeBSD does not issue advisories for local denial-of-service issues. It is expected that this bug will soon be fixed in FreeBSD 4.x (it is already fixed in FreeBSD 5.x, as you can see below). Cheers, -- Jacques Vidrine <nectar@freebsd.org> -----

Hi. I noticed that when non-64bit variable is given as a second argument to atomic_add_64() function, the result is invalid. I found few places where such situation occurs. I wonder how this got unnoticed with ztest, which fails on me within a few seconds (after I started to use Solaris atomic operations) on assertions. Maybe this only doesn''t work when compiled with gcc? Not sure, but

Hi. When we don't have too many IP addresses available and we want to run for example www server inside a jail, but use the same IP address as the main system, we need to actually use an internal IP address and forward http port with firewall from external IP to jail's IP. In that way we know that if somebody breaks into out jail, he cannot run sshd server (we have keys, I know) or any

I can''t find anything using those functions. Can they be removed? -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type:

On Sun, Jul 24, 2005 at 04:06:02PM +0200, Poul-Henning Kamp wrote: +> In message <20050724135738.GM46538@darkness.comp.waw.pl>, Pawel Jakub Dawidek writes: +> +> >We should probably test entropy quality on boot. +> >I've somewhere userland version of /sys/dev/rndtest/ which implements +> >FIPS140-2 tests for (P)RNGs. We can use put it into rc.d/ and warn users.

Hi. We''re testing the most recent ZFS version from OpenSolaris ported to FreeBSD. Kris (CCed) observed strange situation. In function arc_read() he had a panic on assertion that we try to unlock a lock which is not beeing held: rw_enter(&pbuf->b_hdr->b_datalock, RW_READER); err = arc_read_nolock(pio, spa, bp, done, private, priority, flags, arc_flags, zb);

Hi. I've no response from so@ in this topic, probably because leak of time, so I'll try here. Here is a patch that I'm planing to commit: http://people.freebsd.org/~pjd/patches/restricted_hardlinks.patch It adds two new sysctls: security.bsd.hardlink_check_uid security.bsd.hardlink_check_gid If sysctl security.bsd.hardlink_check_uid is set to 1, unprivileged users are not

In zfs_mount() function, when we process a mount by a regular user through the delegated administration, the comment states: /* * Make sure user is the owner of the mount point * or has sufficient privileges. */ This makes sense, but the code doesn''t match the comment. The code ensures that user is the owner of the mount point _and_ can write to the directory. Or does "has

ZVOL was recently converted to use range locking, but it seems the comment below wasn''t updated: /* * There must be no buffer changes when doing a dmu_sync() * because * we can''t change the data whilst calculating the checksum. * A better approach than a per zvol rwlock would be to lock * ranges. */ -- Pawel Jakub Dawidek http://www.wheel.pl

Hi. I''ve almost all file system functions working. I started to run some heavy file system regression tests. They work. fsx wasn''t able to break my port, but the test you can find here: http://people.freebsd.org/~kan/fsstress.tar.gz broke it. My kernel panics on this assertion (zfs_dir.c): 749: mutex_exit(&dzp->z_lock); 750: 751: error =

Hi. Someone currently reported a ''ss == NULL'' panic in space_map.c/space_map_add() on FreeBSD''s version of ZFS. I found that this problem was previously reported on Solaris and is already fixed. I verified it and FreeBSD''s version have this fix in place...

Hi. I can''t reach Brendan Gregg with this question (user unknown, he doesn''t work for Oracle anymore?), so I''m sending it here: FreeBSD users report much better performance and lower disk and CPU load when L2ARC also holds prefetched data (l2arc_noprefetch = B_FALSE). I was wondering what was the reason to avoid storing prefetched data on L2ARC vdevs by default. --

----- Forwarded message from Bob Friesenhahn <bfriesen at simple.dallas.tx.us> ----- From: Bob Friesenhahn <bfriesen at simple.dallas.tx.us> Date: Mon, 23 Jul 2012 12:55:44 -0500 (CDT) To: zfs at lists.illumos.org cc: Radio m?odych bandyt?w <radiomlodychbandytow at o2.pl>, Pawel Jakub Dawidek <pjd at FreeBSD.org>, developer at lists.illumos.org Subject: Re: [zfs] LZ4

Hi. I have a series of patches to sandbox dhclient using Capsicum (capability mode and capability rights for descriptors). As usual, because chroot and setgid/setuid are not sandboxing mechanisms, there are many problems with the current sandboxing: - Access to various global namespaces (like process list, network, etc.). - Access to RAW UDP socket. - Read/write access to bpf. - Access to RAW

I''m CCing zfs-discuss at opensolaris.org, as this doesn''t look like FreeBSD-specific problem. It looks there is a problem with block allocation(?) when we are near quota limit. tank/foo dataset has quota set to 10m: Without quota: FreeBSD: # dd if=/dev/zero of=/tank/test bs=512 count=20480 time: 0.7s Solaris: # dd if=/dev/zero of=/tank/test bs=512 count=20480 time: 4.5s