Keeping your coding directory secure...
I've used the Cryptographic
File System for a while now. It's a bit of a misnomer, though, as
it's not really a separate partition with its own filesystem encrypted
somehow (of which enough exist anyway).
You have a directory whose entire contents are encrypted, although the files are still plain files with encrypted content. You perform a specific cattach command, and this creates a directory under a special NFS mount point. This directory is the unencrypted version of your encrypted directory: a read goes through NFS to the local cfs daemon, which fetches the block you want and decrypts it. Writes happen in a similar but reverse fashion. So your files are never ever seen as an actual cleartext sitting on an unencrypted filesystem. There's a further variant where the NFS sees the encrypted file and not the unencrypted one, and which therefore allows you to run encrypted shares across a network (whereas CFS would leak like a sieve).
The minor problem is that there's a bug on the x86_64 platform. I can
create an entire new encrypted directory and the password is correct, but
the cattach command just says cattach: incorrect
passphrase. I don't know exactly where it's caused; I haven't
scrutinised the code. (Again the tyrrany of Open Source... :-). I don't
know if this also affects the PPC architecture as well. But for the rest
of us running on i386, it's a very useful way to keep those little bits
of your filesystem that you don't want to share with others nice and secure.
posted at: 16:54 | path: /tech | permanent link to this entry
Scratching the Surface of SELinux
In restoring the server to its former glory I needed to restore the
installation of Lahey Fortran for our old Fortran programmers. (With
Fortran programmers, as with Fortran, one learns to not question why
they need to do something, or to ask them to learn something new, but
to just work with what they're giving you. I'm not about to start
asking them why they can't write their programs in some version of
Fortran that the GNU Fortran compiler supports...)
Unfortunately, running the program gave me the error "library name: cannot restore segment prot after reloc: Permission denied. ". A Google on this error message showed me that it's caused by SELinux, which doesn't just allow anyone to come along and install new shared object libraries - you have to make sure that they're set to be a shared library (type 'texrel_shlib_t'). So applying the command 'chcon -v -t texrel_shlib_t /path/to/library' made everything suddenly work. And made me learn a little more about how SELinux sits in with all the other parts of Linux.
Learning: it's a good thing.
posted at: 16:50 | path: /tech/fedora | permanent link to this entry
Where's the Bloody Bluetooth?!
Resisting the temptation to rant, I'll just say that I'm struggling to get
bluetooth working under Fedora. I can get the hci device started
(hciconfig hci0 up, surprisingly enough!) and see the phone via
hcitool (and another device only identified as "SuperDuper", which no-one
in the lab is owning up to owning ;-). I can even get an RFCOMM device
connected to the phone in question using sdptool. From there it goes
downhill.
Gnome-bluetooth-manager doesn't see anything when I do a scan. Gnokii
seems fixated on /dev/ttyS0, and infuriatingly impossible to move to any
other TTY port. There doesn't seem to be a lot else to use. A
quick google doesn't show up much. I'd appreciate
an email from anyone that has
been able to successfully transfer their phonebook from one phone to
another via bluetooth in Gnome, or Fedora, or Linux, or anything that
isn't proprietary.
posted at: 15:33 | path: /tech | permanent link to this entry
All posts licensed under the CC-BY-NC license. Author Paul Wayper.