Duplicated volumes under Live-USB

[frisco]

This bug report applies to r1126 of the deb-live build, based on cryptobox-server 3.4.5.

Some disks are listed twice in the "Disks" web page view. In the attached screen shot, there is one plaintext and one LUKS volume listed even though only one 37 GB disk actually exists. The "Disks" comes directly from reread_container_list().

From trunk/src/cryptobox/core/main.py:

148 	    def reread_container_list(self):
149 	        """Reinitialize the list of available containers.
150 	
151 	        This should be called whenever the available containers may have changed.
152 	        E.g.: after partitioning and after device addition/removal
153 	        """
154 	        self.log.debug("rereading container list")
155 	        self.__containers = []
156 	        blockdevice.CACHE.reset()
157 	        for device in blockdevice.Blockdevices().get_storage_devices():
158 	            if self.is_device_allowed(device) and not self.is_config_partition(device):
159 	                self.__containers.append(cbxContainer.CryptoBoxContainer(device, self))
160 	        ## sort by container name
161 	        self.__containers.sort(cmp = lambda x, y: x.get_name() < y.get_name() and -1 or 1)

This is where most of the "special-case" filtering takes place. Checking whether a partition is part of the live-media could be added here.

From trunk/src/cryptobox/core/main.py:

239 	    def get_container_list(self, filter_type=None, filter_name=None):
240 	        "retrieve the list of all containers of this cryptobox"
241 	        try:
242 	            result = self.__containers[:]
243 	            if filter_type != None:
244 	                if filter_type in range(len(cbxContainer.CONTAINERTYPES)):
245 	                    return [e for e in self.__containers if e.get_type() == filter_type]
246 	                else:
247 	                    self.log.info("invalid filter_type (%d)" % filter_type)
248 	                    result.clear()
249 	            if filter_name != None:
250 	                result = [e for e in self.__containers if e.get_name() == filter_name]
251 	            return result
252 	        except AttributeError:
253 	            return []

Note that the only filtering that takes place at this point is by name and filesystem type.

From trunk/src/cryptobox/core/container.py:

34 	CONTAINERTYPES = {
35 	    "unused":0,
36 	    "plain":1,
37 	    "luks":2,
38 	    "swap":3,
39 	    }
40 	
41 	FSTYPES = {
42 	    "plain":["ext3", "ext2", "vfat", "reiserfs", "xfs", "hfs", "jfs", "minix", "ntfs"],
43 	    "swap":["swap"]}

From this list it's easy to see that the live-cd would not have been in the list of containers because "iso9660" isn't in the "plain" list, but that live-USB media would show up because it's formatted as "vfat". This has in fact happened, though not shown in the attachment "Bogus disks.png"

I don't totally understand why mounted LUKS volume appear twice, given that /dev/mapper devices shouldn't be listed in the "Disks" list and don't appear to be covered by the "allowed devices" mechanism.

I noticed that the two duplicate disks in my example have different names.

Below this point is rambling speculation; don't give it too much attention:
One factor may be that the disk-naming mechanism, which uses UUIDs, may assume the presence of a persistent configuration partition, which was not present in most of my tests. The Debian Live situation may be a bit different from dfsbuild regarding what happens with no configuration partition. Users are allowed to run the CryptoNAS without a configuration partition, so making the /var/cache/cryptobox-server/config (?) directory read-only isn't a good option.

[frisco]

Screen shot of duplicated disks

[Frisco]

This appears to have been the result of changes to config handling that occurred somewhere between the 0.3.1 release and October 2008. I was unable to duplicate the bug when I tried every method I could think of around October 2008, but it's possible I could have forgotten some of the conditions which caused the problem to appear. This could also have been caused by bugs #214 and #215 under some circumstances.

Please reopen this bug if you are experiencing this issue with config partitions created with releases later than 0.3.4.5.