KalNet Message Board

The simplest way to create a group that owns files is to employ adduser(8) to
make a user that owns them, and utilize that user’s primary group as the group
for the files. Because we already have a user called bind, we’ll create an admin-
istrative user dns. The username isn’t important, but you should choose a
name that you’ll remember easily.

Give your administrative user a shell of nologin, which sets a shell of
/sbin/nologin. This prevents anyone from actually logging in as the admin-
istrative user.

If you want, you could specify a particular UID and GID for these sorts of
users. I’ve been known to choose UID and GID numbers that resemble those
used by their related service accounts. For example, the user bind has a UID
and GID of 53. I could give the user dns a UID of 10053 to make it easily
recognizable. At other times, I start numbering my administrative groups at
65535 and work my way down. It doesn’t matter so long as I’m completely
consistent within an organization.

Do not add this administrative user to any other groups. Under no
circumstances add this user to a privileged group such as wheel! Every user
needs a home directory. For an administrative user, a home directory of
/nonexistent works well. This user’s files are elsewhere in the system, after all.
Lastly, let adduser(8) disable the account. While the shell prevents logins, an
extra layer of defense won’t hurt.

Now that you have an administrative user and a group, you can assign
ownership of files to that user. A user and a group own every file. You can see
existing file ownership and permissions with ls -l. (If you’ve forgotten how
Unix permissions work, read ls(1) and chmod(1).) Many sysadmins pay close
attention to file owners, somewhat less attention to worldwide permissions,
and only glance at the group permissions.

Now that you have an administrative user and a group, you can assign
ownership of files to that user. A user and a group own every file. You can see
existing file ownership and permissions with ls -l. (If you’ve forgotten how
Unix permissions work, read ls(1) and chmod(1).) Many sysadmins pay close
attention to file owners, somewhat less attention to worldwide permissions,
and only glance at the group permissions.

Code: Select all

# ls -l
total 3166
-rw-r----- 1 mwlucas mwlucas 79552 Nov 11 17:58 rndc.key
-rw-rw-r-- 1 mwlucas mwlucas 3131606 Nov 11 17:58 absolutefreebsd.com.db

Here, I’ve created two files. The first file, rndc.key, can be read and
written by the user mwlucas, it can be read by anyone in the group mwlucas,
but no one else can do anything with it. The file absolutefreebsd.com.db can be
read or written by the user mwlucas or anyone in the group mwlucas, but
others can only read the file. If you’re in the group mwlucas, you can edit the
file absolutefreebsd.com.db without becoming root.

Change a file’s owner and group with chown(1). You must know the
name of the user and group whose ownership you want to change. In this
case, we want to change both files to be owned by the user dns and the
group dns.

Code: Select all

# chown dns:dns rndc.key
# chown dns:dns absolutefreebsd.com.db
# ls -l
total 3166
-rw-r----- 1 dns dns 79552 Nov 11 17:58 rndc.key
-rw-rw-r-- 1 dns dns 3131606 Nov 11 17:58 absolutefreebsd.com.db

These files are now owned by the user dns and the group dns. Anyone
who is in the group dns can edit absolutefreebsd.com.db without using the root
password. Finally, this file can be read by the user bind, who runs the name-
server. Add your DNS administrators to the dns group in /etc/group, and
abruptly they can do their jobs.
The DNS administrators might think that they need the root password
for restarting the nameserver program itself. However, this is easily managed
with rndc(8). Other tasks can be managed with cron jobs, or with the add-on
program sudo(8).

THEJEW:*:*****:THEJEW
KALBOB:*:*****:KALBOB
JASON:*:*****:JASON
MEGAN:*:******:MEGAN
MEDIA:*:******:MEDIA,THEJEW,KALBOB,JASON,MEGAN,HTPC
HTPC:*:******:HTPC,THEJEW

$ chown -R THEJEW:MEDIA /tank/MEDIA

$ ls -l
drwxr-x---  12 THEJEW  MEDIA  26 Jun 25 14:14 MEDIA

Setting up an encrypted ZFS with FreeBSD
Posted on March 2, 2008, 15:26, by dsp, under Open Source.

I usually want to have my disks encrypted. As all my storage servers run on recent FreeBSDs I usually use GEOM ELI, also known as GELI, to encrypt the disks. Geli is pretty straight forward, runs out of the box on FreeBSD and is easy to set up. So when updating my storage by buying two 500GB disks, I wanted to checkout the ZFS implementation on FreeBSD which is available, but still experimental, on FreeBSD 7.0.

What is ZFS?
ZFS is more than just a filesystem. While usually volume manager and filesystems are separated, Sun’s ZFS combines both. It gives you one command to do both, setting up RAID configuration, setting mountpoints and creating filesystems. In addition to that it can address uo 16 Exbibytes. What makes ZFS sexy is that it gives you a very powerful but easy way to set up RAID-0, RAID-1 or RAID-5 (in fact RAID-Z) with just one command. You can also export and import filesystems and creating snapshots, and just move the complete filesystem to another location. Just take a look at the various ZFS related sites about the featureset. It is planned to implement disk encryption on ZFS, but at the moment neither the Sun Solaris implementation nor the FreeBSD implementation support encryption of ZFS filesystems.

Luckily FreeBSD includes a rock solid, easy to use block device encryption that can be used to encrypt disks on a lower level than the filesystem. We are going to use this interface, called GELI to setup our encrypted ZFS.

So first of all, we prepare our keys that will be used to decrypt and encrypt our disks. You can separate keys into a keyfile and a password. Only the combination of both can decrypt the disk.

Code: Select all

#dd if=/dev/random of=/root/ad4.key bs=64 count=1
    #dd if=/dev/random of=/root/ad6.key bs=64 count=1 

We now initialize our encryption with our generated keys. You will be promoted for a password

Code: Select all

# geli init -s 4096 -K /root/ad4.key /dev/ad4
    Password:
    # geli init -s 4096 -K /root/ad6.key /dev/ad6
    Password: 

And attach them, so that we can write on the disk. With attaching, we start decrypting the content of the disks so it is accessable to the filesystem.

Code: Select all

# geli attach -k /root/ad4.key /dev/ad4
    # geli attach -k /root/ad6.key /dev/ad6 

We know have two new devices: /dev/ad4.eli and /dev/ad6.eli. /dev/ad4 and /dev/ad6 is encrypted, while /dev/ad4.eli and /dev/ad6.eli is decryped.
We can work with the later one like with every other disk.

If you want to make things a little bit safer, so that you are sure no old content is on the disk, rewrite the complete disk
using dd.

Code: Select all

# dd if=/dev/random of=/dev/ad4.eli bs=1m
    # dd if=/dev/random of=/dev/ad6.eli bs=1m 

Now create our ZFS mirror on top of that

Code: Select all

# zpool create -f tank mirror ad4.eli ad6.eli 

We use the -f switch here if your disks differ in size a little bit (this will usually happen if you work usb sticks or something equal)

After that, we have to setup the necessary startup files, so that we will be prompted for the password on the next boot and that the ZFS will be mounted automaticly

In /boot/loader.conf

Code: Select all

 zfs_load=”YES”
    vm.kmem_size_max=”1073741824″
    vm.kmem_size=”1073741824″ 

The later two options are necessary as ZFS eats a lot of kernel memory (see ZFS Tuning Guide: for more details)

In /etc/rc.conf

Code: Select all

geli_devices=”ad4 ad6″
    geli_ad4_flags=”-k /root/ad4.key”
    geli_ad6_flags=”-k /root/ad6.key”
    geli_autodetach=”NO”
    zfs_enable=”YES” 

The zfs_enable switch will cause ZFS to mount the partitions on startup. The geli_devices=”ad4 ad6″ will cause geli to setup both devices on startup while the appropriate flags help to find the keyfile for the decryption.

Notice that geli_autodetach MUST be NO. Using ZFS geli sometimes detaches even if ZFS writes on the devices, causing an anoying core dump.

After that, just reboot, you will be asked for the password of your disk. If your finished booting, your ZFS will be available like every other file system.
Type

Code: Select all

# zpool status
    pool: tank
    state: ONLINE
    scrub: none requested
    config:

    NAME STATE READ WRITE CKSUM
    tank ONLINE 0 0 0
    mirror ONLINE 0 0 0
    ad4.eli ONLINE 0 0 0
    ad6.eli ONLINE 0 0 0

    errors: No known data errors 

to see the status of your ZFS system.

Just a quick advice. It is always a good idea to start by labeling your disks before you add them to a pool. The reason for this is that it makes disk management easier in case of a disk replacement. I would start by completely destroying any existing partitions:

Code: Select all

gpart destroy ad4 (ad6, ad8)

Then I would label my disks:

Code: Select all

glabel label -v disk1 /dev/ad4
glabel label -v disk2 /dev/ad6
glabel label -v disk3 /dev/ad8

After that I would create the pool:

Code: Select all

zpool create tank raidz1 label/disk1 label/dik2 label/disk3

That would give me something like the following:

Code: Select all

  pool: tank
 state: ONLINE
 scrub: scrub completed after 1h46m with 0 errors on Tue Aug 17 03:21:46 2010
config:

   NAME              STATE     READ WRITE CKSUM
   tank              ONLINE       0     0     0
     raidz1          ONLINE       0     0     0
       label/zdisk1  ONLINE       0     0     0
       label/zdisk2  ONLINE       0     0     0
       label/zdisk3  ONLINE       0     0     0

errors: No known data errors

George