Monthly Archives: June 2015

Crock Pot Hacks

linuxfunnies

As part of its new push into the Internet of Things, Belkin this week unveiled its Linux-powered slow cooker at CES in Las Vegas. Just think of all the ways you could use this!

http://www.muktware.com/2014/01/belkin-shows-linux-powered-smart-slow-cooker-ces-2014/18852

 

Setting up Raspberry Pi as a DHCP, NTP, and DNS server

Little Service

The versatile Raspberry Pi can serve many roles on a home network. We’ll show you how to set up the Pi to provide some important network services.

The tiny US$ 35 Raspberry Pi computer [1] is gaining attention around the world as an education tool and a plaything for hobbyists. But, many users are discovering that the Rasp Pi can do real, practical things for a small network. After all, the Raspberry Pi is a real Linux computer, complete with an Ethernet port and USB ports.

The system is admittedly light on resources – with only 512MB memory and file storage on an SD card, but for simple tasks that aren’t too resource-intensive, the Pi performs well. The fact that the Pi runs with very low power usage and hardly takes up any space are actually benefits in some scenarios, especially on home networks with little space and low demand.

This article describes how to set up the Raspberry Pi to perform a few common network services, including:

  • IP address allocation with DHCP
  • Time Service with NTP
  • Name service with Bind9

DHCP service is often performed by a home router or through the ISP’s own DHCP server. However, DSL routers are sometimes overwhelmed with the task of managing a medium-sized home network, and they sometimes don’t support a full range of DHCP services, such as assignment of fixed IP addresses.

Assigning IP addresses with a Raspberry Pi might seem like an improbable solution, but, in some cases, you might find it actually performs better than leaving this task to your home router. And anyway, at a minimum, you get some experience configuring network services, and you’ll learn more about your Pi along the way.

A DNS server might seem even more improbable, because you have most likely gotten by just fine up until now without using a Raspberry Pi for name resolution, but this little exercise in network configuration shows the Pi at its best: a versatile tool that lets you experiment and explore without a lot of complication or risk. (See the box titled “Home DNS” for a look at some possible benefits.)

Home DNS

Name resolution on your own server is more than three times faster than resolution by external DNS servers, mainly because repeat requests can be answered from the internal cache instead of querying DNS servers on the Internet. To demonstrate this, consider the following experiment.

Multiple queries through Google’s name servers required the following time profile:

fritz@fhserver:~>   time (for i in `seq 1 1000`;   do dig google.com @8.8.8.8 >   /dev/null 2>>/dev/null; done)
real    0m24.156s
user    0m4.825s
sys     0m3.517s

A similar sequence sent to my ISP’s name server (Telecom) required the following:

fritz@fhserver:~>   time (for i in `seq 1 1000`;   do dig google.com   @217.237.148.70 >   /dev/null 2>>/dev/null; done)
real    0m27.430s
user    0m5.088s
sys     0m3.406s

My internal name server returned the names much faster, because it was able to make better use of caching:

fritz@fhserver:~>   time (for i in `seq 1 1000`;   do dig google.com @127.0.0.1 >   /dev/null 2>>/dev/null; done)
real    0m7.632s
user    0m4.305s
sys     0m2.736s

Of course, all of this takes place for a single name resolution within milliseconds and is therefore not of practical importance for a home network. However, it does illustrate the potential benefits of an internal name server. Another benefit of a home DNS server is that it gives you one central point for managing host names on your network.

In this case, note that the local network occupies a private, non-routable address range (192.168.100…), which is mapped to the Internet address space through Network Address Translation (NAT). The use of DNS with NAT complicates this solution if you want the DNS server to be accessible from beyond the network.

You might be wondering how this DNS server will map names to IP addresses if the IP addresses are dynamically assigned through DHCP. Of course, dynamic DNS is available for mapping permanent host names to temporary IP addresses. For the purposes of this simple configuration, I will configure the DHCP server to assign a fixed address to the client based on the MAC address.

Static IP Address

The Rasp Pi needs a static IP address to work as a DHCP server. You can start by determining which address the DSL router has assigned to the Rasp Pi (Listing 1).You can use the route command to determine the default gateway (the address of the DSL router; see Listing 2 for example).

Listing 1

Finding the IP Address

# ifconfig displays the current configuration of the Ethernet interface
fritz@raspberrypi ~ $ ifconfig a
eth0      Link encap:Ethernet  HWaddr b8:27:eb:80:7d:b8
          inet addr:192.168.100.73  Bcast:192.168.100.255  Mask:255.255.255.0

Listing 2

DSL Router Address

fritz@raspberrypi ~ $ route
Kernel IP routing table
Destination     Gateway         Genmask...
default         192.168.100.1   0.0.0.0...
192.168.100.0   *               255.255.255.0...

All the network addresses look like this: 192.168.100.x (or a.b.c.x, if the output was a.b.c.d). The DSL router address must not be assigned to any other device. I’ll configure the Rasp Pi to use 192.168.100.2 as a permanent address by configuring a static address in /etc/network/interfaces (Listing 3).

Listing 3

/etc/network/interfaces

auto lo
iface lo inet loopback
iface eth0 inet dhcp
iface eth0 inet static
address 192.168.100.2
netmask 255.255.255.0
gateway 192.168.100.1
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

Configuring NTP on the Rasp Pi

In the Raspbian image, which you can download from the Internet, NTP is already installed. However, if you want to use the Pi as a time server, you might want to change the different servers to the NTP pool defined in the config file. You need to edit the /etc/ntp.conf file and add servers to the NTP pool (see Listing 4).

Listing 4

/etc/ntp.conf

# You do need to talk to an NTP server or two (or three).
# server ntp.your-provider.example
# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: http://www.pool.ntp.org/join.html
#server 1.debian.pool.ntp.org iburst
#server 2.debian.pool.ntp.org iburst
#server 3.debian.pool.ntp.org iburst
server 0.de.pool.ntp.org iburst
server 1.de.pool.ntp.org iburst
server 2.de.pool.ntp.org iburst
server 3.de.pool.ntp.org iburst

You will find more information online [2]. In Listing 4, I have commented out the Debian time servers and added more servers in my home country to the NTP server pool.

I still need to negotiate a minor obstacle. If the IP address is retrieved via DHCP (which was the case until I convert to the static IP address), the time server configuration is not read from the /etc/ntp.conf file but from /var/lib/ntp/ntp.conf.dhcp. Things will stay this way as long as this file exists in the /var directory.

The time server registered in this file was the one assigned by the DHCP server, typically the address of the DSL server. First, make sure the static IP address is active (after changing /etc/network/interfaces, reboot your Rasp Pi – sudo init 6). Then, delete /var/lib/ntp/ntp.conf.dhcp, and again reboot your Rasp Pi. After a couple minutes, you can use the following:

ntpq -p

to check the configuration of the time server. The resulting output is shown in Listing 5.

Listing 5

Time Server Configuration

fritz@raspberrypi ~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+imap.immobilien .PPS.            1 u   41   64    1   79.383   -0.553   1.211
+195.50.171.101  145.253.2.212    2 u    5   64    1   11.553   -1.133   1.247
*stratum2-4.NTP. 129.70.130.70    2 u    9   64    1   17.939   -1.059   0.146
-ntp.uni-oldenbu 192.53.103.104   2 u   40   64    1   24.178   -0.018   0.811

Installing the Name Server

The Bind9 (Berkeley Internet name service) package is responsible for name resolution. Bind9 is pretty easy to install with apt-get. You need to make sure your Rasp Pi has a large enough SD card (4GB or more, or preferably 16GB). Additionally, you should install the DNS-utils to provide useful commands, such as nslookup and dig. A check with nslookup shows that the Rasp Pi is still using the DSL server as its master, so I need to modify /etc/resolv.conf. You can find directories of free name server addresses online. For my locale, I found name servers through sites such as http://www.freie-nameserver.de/ or http://www.ungefiltert-surfen.de/nameserver/de. I can then enter these name servers in the /etc/resolv.conf file (Listing 6).

Listing 6

Configuring resolv.conf

01 fritz@raspberrypi ~ $ sudo apt-get install bind9
02 fritz@raspberrypi ~ $ sudo apt-get install dnsutils
03 nslookup www.telekom.de
04 Server:         192.168.100.2
05 Address:        192.168.100.2#53
06 Non-authoritative answer:
07 Name:   www.telekom.de
08 Address: 217.150.151.99
09
10 fritz@raspberrypi ~ $ sudo vi /etc/resolv.conf
11 domain homenet.de
12 search homenet.de
13 nameserver 127.0.0.1
14 nameserver 194.187.164.20
15 nameserver 193.158.224.9
16 nameserver 80.239.175.131
17 nameserver 80.239.207.176
18 nameserver 212.211.132.4
19 nameserver 212.43.68.10
20 nameserver 81.209.130.140
21 nameserver 213.30.253.65
22 nameserver 141.2.1.3
23
24 fritz@raspberrypi ~ $ nslookup www.telekom.de
25 Server:         127.0.0.1
26 Address:        127.0.0.1#53
27 Non-authoritative answer:
28 Name:   www.telekom.de
29 Address: 217.150.151.99

The Local Zone

To understand the names of the devices on my own network, I need to add a local zone. First, I add the line listen-on port 53 {any;}; to /etc/bind/named.conf.options, and reference to the zone files in /etc/bind/named.conf.local. I then need to create the zone files with the names and IP addresses of all the devices on the home network (Listing 7), as well as the associated reverse zone file (Listing 8). The dots in lines like homenet.de. are important. If the dot is missing at the end, the system appends the domain name (homenet.de), and then the name no longer matches.

Listing 7

Zone file /etc/bind/zone.homenet.de

01 // Do any local configuration here
02 //
03 // Consider adding the 1918 zones here, if they are not used in your
04 // organization include "/etc/bind/zones.rfc1918";
05 //
06 //
07 zone "homenet.de"
08 {
09 type master ;
10 file "/etc/bind/zone.homenet.de" ;
11 } ;
12 //
13 zone "0.100.168.192.in-addr.arpa"
14 {
15 type master ;
16 notify no ;
17 file "/etc/bind/zone.0.100.168.192.in-addr.arpa" ;
18 } ;
19 References to the zone files are added to /etc/bind/named.local.
20 $TTL 2d
21 @               IN SOA          pi.homenet.de.    root.pi.homenet.de. (
22                                 2013080701      ; serial
23                                 3h              ; refresh
24                                 1h              ; retry
25                                 1w              ; expiry
26                                 1d )            ; minimum
27
28 homenet.de.     IN NS           pi.homenet.de.
29 vectra          IN A            192.168.100.1
30 fhserver        IN A            192.168.100.2
31 fritz-pc        IN A            192.168.100.50
32 fpc-wlan        IN A            192.168.100.51
33 andrey-laptop   IN A            192.168.100.52
34 andrey-lap-wire IN A            192.168.100.53
35 lena-laptop     IN A            192.168.100.54
36 lena-lap-lan    IN A            192.168.100.55
37 frlap-wlan      IN A            192.168.100.56
38 frlap-lan       IN A            192.168.100.57
39 andrey-pc       IN A            192.168.100.58
40 fritz-ipad      IN A            192.168.100.59
41 andrey-gpad     IN A            192.168.100.60
42 fritz-phone     IN A            192.168.100.61
43 andrey-phone    IN A            192.168.100.62
44 sony-tv         IN A            192.168.100.63
45 screenplay      IN A            192.168.100.64
46 pioneer-av      IN A            192.168.100.65
47 printserver     IN A            192.168.100.66
48 wlan-router     IN A            192.168.100.67
49 pioneer-bd      IN A            192.168.100.68
50 fritz-vmlinux   IN A            192.168.100.69
51 fritz-vm98      IN A            192.168.100.70
52 fritz-vmdos     IN A            192.168.100.71
53 noxon           IN A            192.168.100.72
54 pi              IN A            192.168.100.73

Listing 8

The “reverse” Zone File

01 $TTL 2d
02 @               IN SOA          pi.homenet.de.    root.pi.homenet.de. (
03                                 2013080703      ; serial
04                                 3h              ; refresh
05                                 1h              ; retry
06                                 1w              ; expiry
07                                 1d )            ; minimum
08
09 100.168.192.in-addr.arpa.       IN NS           pi.homenet.de.
10 1.100.168.192.in-addr.arpa.     IN PTR          vectra.homenet.de.
11 2.100.168.192.in-addr.arpa.     IN PTR          fhserver.homenet.de.
12 50.100.168.192.in-addr.arpa.    IN PTR          fritz-pc.homenet.de.
13 51.100.168.192.in-addr.arpa.    IN PTR          fpc-wlan.homenet.de.
14 52.100.168.192.in-addr.arpa.    IN PTR          andrey-laptop.homenet.de.
15 53.100.168.192.in-addr.arpa.    IN PTR          andrey-lap-wire.homenet.de.
16 54.100.168.192.in-addr.arpa.    IN PTR          lena-laptop.homenet.de.
17 55.100.168.192.in-addr.arpa.    IN PTR          lena-lap-lan.homenet.de.
18 56.100.168.192.in-addr.arpa.    IN PTR          frlap-wlan.homenet.de.
19 57.100.168.192.in-addr.arpa.    IN PTR          frlap-lan.homenet.de.
20 58.100.168.192.in-addr.arpa.    IN PTR          andrey-pc.homenet.de.
21 59.100.168.192.in-addr.arpa.    IN PTR          fritz-ipad.homenet.de.
22 60.100.168.192.in-addr.arpa.    IN PTR          andrey-gpad.homenet.de.
23 61.100.168.192.in-addr.arpa.    IN PTR          fritz-phone.homenet.de.
24 62.100.168.192.in-addr.arpa.    IN PTR          andrey-phone.homenet.de.
25 63.100.168.192.in-addr.arpa.    IN PTR          sony-tv.homenet.de.
26 64.100.168.192.in-addr.arpa.    IN PTR          screenplay.homenet.de.
27 65.100.168.192.in-addr.arpa.    IN PTR          pioneer-av.homenet.de.
28 66.100.168.192.in-addr.arpa.    IN PTR          printserver.homenet.de.
29 67.100.168.192.in-addr.arpa.    IN PTR          wlan-router.homenet.de.
30 68.100.168.192.in-addr.arpa.    IN PTR          pioneer-bd.homenet.de.
31 69.100.168.192.in-addr.arpa.    IN PTR          fritz-vmlinux.homenet.de.
32 70.100.168.192.in-addr.arpa.    IN PTR          fritz-vm98.homenet.de.
33 71.100.168.192.in-addr.arpa.    IN PTR          fritz-vmdos.homenet.de.
34 72.100.168.192.in-addr.arpa.    IN PTR          noxon.homenet.de.
35 73.100.168.192.in-addr.arpa.    IN PTR          pi.homenet.de.

If you are interested in more details of the Bind configuration, the content of the files presented here, and the importance of each entry, I recommend the DNS & BIND Cookbook [3]. If you want to completely invest yourself in the functionality of the domain name service, I also recommend DNS & BIND [4].

Address List

The home network now has a central time server and a name server. However, I have to make sure the computers on the network match the IP addresses assigned to them in the zone file. I first need to configure the DHCP server. Only one DHCP server can be active in any subnet, so I need to shut down the DHCP service on the DSL router. To do this, I must consult the user manual for my DSL router.

First, I need to install the DHCP service on the Rasp Pi using apt-get. The fact that automatic startup doesn’t initially work, is okay. I only need to change the /etc/dhcp/dhpd.conf file (Listing 9). After starting the DHCP service with sudo /etc/init.d/isc-dhcp-server, the DHCP server should work. Now, when I start up a network device, I can see from the /var/log/syslog file how an IP address is assigned to the device (Listing 10).

Listing 9

Map Hardware Addr to IP Addr

001 option domain-name "homenet.de";
002 option domain-name-servers pi.homenet.de;
003 option routers fhserver.homenet.de;
004 option ntp-servers pi.homenet.de;
005 option lpr-servers printserver.homenet.de;
006 ddns-update-style none;
007 max-lease-time 345600;
008 default-lease-time 172800;
009 subnet 192.168.100.0 netmask 255.255.255.0 {
010   authoritative ;
011   get-lease-hostnames on;
012   use-host-decl-names on;
013   range dynamic-bootp 192.168.100.100 192.168.100.254;
014   default-lease-time 14400;
015   max-lease-time 172800;
016 }
017 host vectra {
018   fixed-address vectra.homenet.de;
019   hardware ethernet 00:04:76:97:5B:1C;
020 }
021 host fhserver {
022   fixed-address fhserver.homenet.de;
023   hardware ethernet BC:5F:F4:66:ED:DE;
024 }
025 host fritz-pc {
026   fixed-address fritz-pc.homenet.de;
027   hardware ethernet 90:E6:BA:3D:1D:95;
028 }
029 host fpc-wlan {
030   fixed-address fpc-wlan.homenet.de;
031   hardware ethernet 70:1A:04:2D:54:9F;
032 }
033 host andrey-laptop {
034   fixed-address andrey-laptop.homenet.de;
035   hardware ethernet 00:17:42:21:60:7D;
036 }
037 # Andrey's Laptop wire-addy come here
038 #
039
040 host lena-laptop {
041   fixed-address lena-laptop.homenet.de;
042   hardware ethernet 00:C0:A8:D6:F4:1C;
043 }
044 host lena-laptop-lan {
045   fixed-address lena-laptop-lan.homenet.de;
046   hardware ethernet 00:17:42:21:60:82;
047 }
048 host frlap-wlan {
049   fixed-address frlap-wlan.homenet.de;
050   hardware ethernet B4:74:9F:EC:93:F3;
051 }
052 host frlap-lan {
053   fixed-address frlap-lan.homenet.de;
054   hardware ethernet 5C:9A:D8:E1:1B:37;
055 }
056 host andrey-pc {
057   fixed-address andrey-pc.homenet.de;
058   hardware ethernet 00:30:05:9A:87:70;
059 }
060 host fritz-ipad {
061   fixed-address fritz-ipad.homenet.de;
062   hardware ethernet 04:54:53:27:BF:C1;
063 }
064 host andrey-gpad {
065   fixed-address andrey-gpad.homenet.de;
066   hardware ethernet B0:D0:9C:3B:81:73;
067 }
068 host fritz-phone {
069   fixed-address fritz-phone.homenet.de;
070   hardware ethernet 20:64:32:2A:CC:6B;
071 }
072 host sony-tv {
073   fixed-address sony-tv.homenet.de;
074   hardware ethernet F0:BF:97:87:62:38;
075 }
076 host screenplay {
077   fixed-address screenplay.homenet.de;
078   hardware ethernet 00:10:D7:81:5A:01;
079 }
080 host pioneer-av {
081   fixed-address pioneer-av.homenet.de;
082   hardware ethernet 00:E0:36:EF:E0:B6;
083 }
084 host printserver {
085   fixed-address printserver.homenet.de;
086   hardware ethernet 00:40:01:27:5A:81;
087 }
088 host wlan-router {
089   fixed-address wlan-router.homenet.de;
090   hardware ethernet 00:14:6C:5A:90:6A;
091 }
092 host pioneer-bd {
093   fixed-address pioneer-bd.homenet.de;
094   hardware ethernet 74:5E:1C:02:6A:06;
095 }
096 host fritz-vmlinux {
097   fixed-address fritz-vmlinux.homenet.de;
098   hardware ethernet 00:0C:29:01:1F:FB;
099 }
100 host fritz-vm98 {
101   fixed-address fritz-vm98.homenet.de;
102   hardware ethernet 00:0C:29:C5:96:10;
103 }
104 host fritz-vmdos {
105   fixed-address fritz-vmdos.homenet.de;
106   hardware ethernet 00:0C:29:41:85:BF;
107 }
108 host noxon {
109   fixed-address noxon.homenet.de;
110   hardware ethernet 00:16:e3:5e:78:06;
111 }
112 host pi {
113   fixed-address pi.homenet.de;
114   hardware ethernet B8:27:EB:80:7D:B8;
115 }

Listing 10

/var/log/syslog

01 Aug  9 15:41:40 raspberrypi dhcpd: DHCPREQUEST for 192.168.100.57 from 5c:9a:d8:e1:1b:37 via eth0
02 Aug  9 15:41:40 raspberrypi dhcpd: DHCPACK on 192.168.100.57 to 5c:9a:d8:e1:1b:37 via eth0
03 Aug  9 3:42:33 PM raspberrypi dhcpd: DHCPINFORM from 192.168.100.50 via eth0
04 Aug  9 3:42:33 PM raspberrypi dhcpd: DHCPACK to 192.168.100.50 (90:e6:ba:3d:1d:95) via eth0
05 Aug  9 15:43:29 raspberrypi named[3769]: client 127.0.0.1#36205: RFC 1918 response from Internet for 57.100.168.192.in-addr.arpa
06 Aug  9 3:43:58 PM raspberrypi dhcpd: DHCPINFORM from 192.168.100.57 via eth0
07 Aug  9 3:43:58 PM raspberrypi dhcpd: DHCPACK to 192.168.100.57 (5c:9a:d8:e1:1b:37) via eth0

Other Options

You can also configure your Rasp Pi as a file, print, or download server. You’ll spend a lot less money (and power) than with a big server system, and if anything goes wrong, you can just start over. That’s the beauty of Raspberry Pi.

Infos

  1. Raspberry Pi: http://www.raspberrypi.org/
  2. NTP Pool Project: http://www.pool.ntp.org/
  3. Liu, Cricket. DNS & Bind Cookbook. O’Reilly Media, 2006.
  4. Liu, Cricket and Paul Albitz. DNS & BIND. O’Reilly Media, 2002. 2IE;

Google teams with Adobe to reduce Flash use in Chrome

Google and Adobe have teamed up to reduce Chrome’s battery usage by cutting down on the amount of Flash content the browser plays automatically.

ted talks logo

These talks will help you reshape how you approach work and see your career in a new light.

Read Now

The new functionality, enabled by default in the latest beta release of Chrome, will automatically pause bits of Flash content the browser determines “arent central to the webpage.” Important items, like the main video on a page, will play uninhibited. If Chrome pauses content that users want to see, they can click on it to resume playback. The change should make webpages with that sort of content load faster and reduce the amount of battery they use.

Google expects to move the Flash-blocking capabilities from Chrome’s beta channel to all users of its browser as soon as September. People who still want to see pages in all their Flash-laden glory can toggle the setting off by ticking “Run all plugin content” in Chrome’s content settings. To re-enable the automatic Flash blocking, toggle “Detect and run important plugin content.”

ADVERTISING

The changes could help Chrome, which has a reputation for being a battery hog relative to other browsers. Tommy Lee, a software engineer and power conservationist at Google, said the feature is aimed at allowing users to “surf the web longer before having to hunt for a power outlet.” (That said, he didn’t provide any concrete numbers about how much battery savings users could expect.)

It’s also potentially bad news for online advertisers who rely on Flash ads. Because that content isn’t central to enjoying a webpage, there’s a chance it will get stopped while a user is browsing rather than continue to run. That’s why Google’s AdWords service allows advertisers to convert new and existing flash campaigns into HTML5, so people will still see the same ads. The company also offers tools for building HTML5 ads, and will soon allow advertisers to upload their own HTML5 campaigns as well.

Getting advertisers away from Flash will also help with mobile advertising efforts from Google and other firms. None of the leading mobile platforms feature native support for Flash, so any advertisements made with it will be blocked from a growing percentage of web traffic. HTML5 ads, on the other hand, will run across devices.

This story, “Google teams with Adobe to reduce Flash use in Chrome” was originally published by IDG News Service\San Francisco bureau.

Kernel News

Inheriting Filesystem Capabilities

Christoph Lameter posted a patch to make filesystem capabilities inheritable the way the SUID bit is. When you set the SUID bit in an executable and another user runs that executable, it runs with your permissions, rather than the permissions of that user. Any files it creates, or other programs it invokes, are likewise run as you instead of as that user.

Capabilities don’t have that kind of inheritability. So, if you write a script and give it certain capabilities, such as allowing raw network access, any scripts invoked by that script will not have the capability to do raw network access. Thus, the script would not be able to rely on any other tools to help do that part of its work. Christoph said, “This is behavior that is counterintuitive to the expected behavior of processes in Unix.”

Making capabilities inheritable, Christoph said, was preferable to simply running executables with the SUID bit set. The SUID bit is a very blunt tool, giving the executable *all* the permissions of its owner; whereas capabilities are more surgical, allowing you to constrain those permissions to just the set what is needed.

Christoph pointed out that this had been a problem for quite awhile and that no better alternative seemed to be available. He remarked that “some involved in security development under Linux have even stated that they want to rip out the whole thing and replace it.” He explained:

This patch does not change the default behavior but it allows to set up a list of capabilities in the proc filesystem that will enable regular unix inheritance only for the selected group of capabilities.

With that it is then possible to do something trivial like setting CAP_NET_RAW on an executable that can then allow that capability to be inherited by others.

Christoph also added, “I usually do not dabble in security and I am not sure if this is done correctly. If someone has a better solution then please tell me but so far we have not seen anything else that actually works.”

Serge Hallyn felt there were some dangers here. POSIX capabilities were tied to the privileges of both the user and the file itself, whereas Christoph’s code seemed to tie capabilities to just the file. Serge suggested adding a new capability, listing the capabilities available to be inheritable by that particular user. The user could then choose which capabilities would be inheritable from a given executable. This way both user privileges and file privileges would be respected.

However, Serge also said, “Not saying this is a good idea necessarily, but worth thinking about.”

Casey Schaufler remarked that the POSIX draft relevant to this whole question was only a draft document that had ultimately been withdrawn. So, there could be no question of true POSIX conformance or lack thereof on this issue. Casey also said:

The POSIX capability scheme is the simplest mechanism we could come up with that allows existing setuid programs to work unmodified and still make it possible to constrain specific capabilities. Is it complicated? Yes. Why is it complicated? Because you need the option of using the file capabilities to raise and lower the privilege of a program. Had we the option of requiring the programs to do that themselves, the whole thing would have been easier. You also need the option of having a capability aware program manipulate it’s own capabilities.

All the UNIX systems that implemented capabilities did so using one variate or another of the POSIX scheme. One, Trusted IRIX, successfully eliminated root privilege.

In terms of Christoph’s comment that some security folks wanted to rip out capabilities entirely and replace them with something else, Casey remarked, “I’m game to participate in such an effort. The POSIX scheme is workable, but given that it’s 20 years old and hasn’t developed real traction it’s hard to call it successful.”

To address POSIX capabilities’ lack of traction over 20 years, Serge said, “I personally think it’s two things: 1. lack of toolchain and fs support. The fact that we cannot to this day enable ping using capabilities by default because of cpio, tar and non-xattr filesystems is disheartening. 2. It’s hard for users and applications to know what caps they need. Yes the API is a bear to use, but we can hide that behind fancier libraries. But using capabilities requires too much in-depth knowledge of precisely what caps you might need for whatever operations library may now do when you asked for something.”

In response to Serge’s first point, Mimi Zohar said, “We’re working on resolving the CPIO issue. tar currently supports xattrs. At this point, how many non-xattr file systems are there really?” Austin Hemmelgarn replied, “FAT* and UFS immediately come to mind, and I know of people who use UFS for their root filesystem.”

In response to Serge’s second point, Casey said, “If the audit system reported the capabilities relevant to the decision you’d have what you need. If you failed because you didn’t have CAP_CHMOD or you succeeded because you had CAP_SYS_ADMIN it should show up in the audit record. Other systems have used this approach.”

Andy Lutomirski, however, didn’t agree with Serge’s point about needing filesystem support. He said, “if I hold a capability and I want to pass that capability to an exec’d helper, I shouldn’t need the fs’s help to do this.” To which Christoph said, “amen!”

At a certain point, Christoph reined in the discussion somewhat, reiterating that the problem had lingered for too long and needed a real live patch. He reiterated that in his patch, “the file being executed can inherit the parent caps without having to set caps in the new executable.” He wasn’t going for anything fancier than that, given that nothing fancier was actually on the table.

Serge said that he actually still preferred his earlier suggestion of introducing a new capability that listed inheritable capabilities. Christoph asked for a real live patch, and, at that point, folks delved into a technical discussion addressing various fine points and implementation details, with objections and affirmations focusing more on the code than on the high-level direction.

At this point, it seems that one form or another of Christoph’s desired inheritability feature will probably eventually go into the kernel. There is still some controversy surrounding it, however. For one thing, as Casey pointed out, POSIX capabilities were never truly standardized. For another, there is an existing base of software that still needs to run properly, on top of whatever solution comes along. And, finally, there are security concerns that trump all other concerns but that also tend to be somewhat convoluted. All of these things are a recipe for compromise that makes it hard to predict what the final result will look like.

Reporting on Inactive CPUs

Some ideas that seem good end up going nowhere, at least for awhile.

Yalin Wang posted a patch to cause /proc/stat to list all CPUs on a running system, regardless of whether a given CPU was online or offline. The reason, he said, was that some CPUs went online or offline dynamically and might need to be tracked. And, if a library wanted to know how many CPUs were on the system, it should get the real number, rather than just the number of CPUs currently online.

David Rientjes liked the idea, but he didn’t think it was necessary to add the information to /proc/stat. The /sys/devices/cpu file reports the number of CPUs in the system. It made more sense to update that file to list all CPUs instead of just online CPUs. Andrew Morton also pointed out that /proc/cpuinfo should be updated to list all CPUs as well.

At this point, however, Yalin hit a stumbling block. In the Android kernel, some code depended on these files to determine the number of online CPUs rather than their total number. If he changed the behavior of those files, he’d break compatibility.

So, that was the end of that.

Adding Timekeeping Tests to the Kernel

John Stultz posted some timekeeping test patches. He’d hosted them on GitHub for a few years, but now he had the time to make them kernel-ready, so he wanted to get some feedback on what he should change.

The tests did things like setting the system time to something that might lead to problems, like that last moment of the last day of the year 1999 or something like that. Some of John’s tests could have a destructive effect along those lines, and some would produce quiet warnings if the system behaved in an improper but non-threatening way.

Richard Cochran liked the patches, and Shuah Khan did as well. She suggested having non-destructive tests run by default and having the user specify destructive tests as desired. She also suggested that John “use kselftest.h reporting mechanism for new tests. posix_timers.c is updated to use it and it would make sense use it for new tests as well.”

John said he’d give that a try, although he also added, “one thing I’ve tried to do with my test suite is minimize any sort of test-infrastructure dependencies, so as much as possible, single test files can be plucked out, built and run by themselves.” But, he said he’d ditch that plan if no one was into it.

Shuah saw the value in his approach and said that adapting to kselftest was not mandatory. She suggested he give it a shot, but “if it does become hard, I am not going to make it a requirement to use it.”

It seems clear that John’s patches will get into the kernel soon, perhaps with some changes. They don’t seem to have any controversy attached.

Freezing File Writes

Namjae Jeon posted some patches to implement file freezing – the idea being that a file write could be blocked temporarily, even if a process already held an open file descriptor. He said, “File write freeze functionality, when used in conjunction with inode’s immutable flag, can be used for creating truly stable file snapshots, wherein write freeze will prevent any modification to the file from already open file descriptors, and immutable flag will prevent any new modification to the file. One of the intended uses for stable file snapshots would be in the defragmentation applications which defrags single file.”

Dmitry Monakhov offered some technical suggestions for Namjae’s patch but overall thought the work was interesting. Jan Kara also had some technical suggestions and pointed out that some of Namjae’s test code contained race conditions. Namjae responded to all suggestions with code and pseudocode that might improve the behavior.

Jan also pointed out some problems with the overall design. Jan said:

Doing fs-wide freezing from userspace makes sense as Dmitry pointed out. We can then just fail FS_IOC_FWFREEZE with error when the whole fs isn’t frozen. I’m just somewhat worried whether the fs-wide freezing won’t be too fragile. E.g. consider a situation when you are running a defrag program which is freezing and unfreezing the filesystem and then some background work kicks which will want to snapshot the file system so it will freeze & unfreeze the fs as well. Now depending on how exactly defrag and snapshot race one of the FIFREEZE ioctls will return EBUSY and the process (hopefully gracefully) fails.

This isn’t a new situation – if you ran two snapshots at once, you’d see the same failure. But the more fs-wide freezing gets used in different places the stranger and less expected failure you’ll see … .

Dave Chinner also had some technical suggestions, although he agreed that some of the code was “terrible racy.” Namjae continued to offer new patches and ideas for how to adapt all the feedback.

It seems as though there are two issues getting in the way of Namjae’s patches. The first would be the race conditions, and the second would be the fragility of the code itself – the likelihood that new race conditions could be inadvertently inserted. Overall, the feature itself – freezing writes – seems like something that no one opposes. So, you could expect some kind of implementation in the not-too-distant future.