Re: [OpenAFS] Additonal question about the OpenAFS Security Advisory 2016-003
> AFS file servers store directory information in a flat file that > consists of a header, a hash table and a fixed number of directory entry > blocks. That I was aware of. > When a volume dump is constructed for a volume move, a volume > release, a volume backup, etc. the contents of the directory files > are copied into the dump stream exactly as they are stored on disk > by the file server. That was the part I was unsure about. Thanks! > I hope this information is helpful. Yes, indeed. Harald. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Additonal question about the OpenAFS Security Advisory 2016-003
On 12/7/2016 11:52 AM, Dave Botsch wrote: > It sounds like running the salvagedirs would result in the next > incremental dump being equiv in size to doing a full dump? I haven't looked at the OpenAFS -salvagedirs implementation in a long while but if it doesn't bump the DV of each directory it rewrites it risks data corruption. The next incremental dump would include all of the directories (which it does in general anyway) but it wouldn't included normal files or symlinks that have not changed. Jeffrey Altman <> smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Additonal question about the OpenAFS Security Advisory 2016-003
It sounds like running the salvagedirs would result in the next incremental dump being equiv in size to doing a full dump? Thanks David William Botsch Programmer/Analyst @CNFComputing bot...@cnf.cornell.edu On December 7, 2016 8:57:54 AM Jeffrey Altman wrote: On 12/7/2016 8:06 AM, Harald Barth wrote: The security advisory says: We further recommend that administrators salvage all volumes with the -salvagedirs option, in order to remove existing leaks. Is moving the volume to another server enough to fix this as well or does the leak move with the volume? The leak will move with the volume. A bit of background for those that are not steeped in the details of the AFS3 protocol and client and file server access for directories. AFS file servers store directory information in a flat file that consists of a header, a hash table and a fixed number of directory entry blocks. When a client reads the contents of a directory, it fetches the directory file in exactly the same way it fetches the contents of normal files and symlinks. The AFS3 callback mechanism works the same for directory files as it does for normal files and symlinks. An AFS dump can be thought of as an AFS specific "tar" variant which stores AFS Volume metadata and data elements. When a volume dump is constructed for a volume move, a volume release, a volume backup, etc. the contents of the directory files are copied into the dump stream exactly as they are stored on disk by the file server. When a volserver receives a dump and writes it to disk as part of a AFSVol_VolForward or AFSVol_Restore operation, each directory file is written to disk as it exists within the dump. Backup systems that store full and incremental dump files do so without modifying the contents during the backup or restore operations. As a result restoring from a backup will restore any leaked information. Backup systems that parse AFS dumps and reconstruct AFS dumps during the restore process might or might not store and restore the leaked information. Contact the provider of your backup system. It is worth emphasizing that IBM AFS and OpenAFS volserver operations including all backup and restore operations occur in the clear. Therefore, all leaked information will be visible to passive viewers on the network segments across which volume backups and moves occur. What the salvager's "-salvagedirs" option does is force the salvager to rewrite every directory object. This has two benefits when performed by a 1.6.20 or later salvager. 1. It will build a directory file that contains no leaked information stored in the original directory file. 2. It will compact the directory to reduce fragmentation that could have resulted in directory full errors when attempting to store a filename that required more directory blocks than are available contiguously. I hope this information is helpful. Jeffrey Altman ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Additonal question about the OpenAFS Security Advisory 2016-003
On 12/7/2016 8:06 AM, Harald Barth wrote: > > The security advisory says: > >> We further recommend that administrators salvage all volumes with the >> -salvagedirs option, in order to remove existing leaks. > > Is moving the volume to another server enough to fix this as well or > does the leak move with the volume? The leak will move with the volume. A bit of background for those that are not steeped in the details of the AFS3 protocol and client and file server access for directories. AFS file servers store directory information in a flat file that consists of a header, a hash table and a fixed number of directory entry blocks. When a client reads the contents of a directory, it fetches the directory file in exactly the same way it fetches the contents of normal files and symlinks. The AFS3 callback mechanism works the same for directory files as it does for normal files and symlinks. An AFS dump can be thought of as an AFS specific "tar" variant which stores AFS Volume metadata and data elements. When a volume dump is constructed for a volume move, a volume release, a volume backup, etc. the contents of the directory files are copied into the dump stream exactly as they are stored on disk by the file server. When a volserver receives a dump and writes it to disk as part of a AFSVol_VolForward or AFSVol_Restore operation, each directory file is written to disk as it exists within the dump. Backup systems that store full and incremental dump files do so without modifying the contents during the backup or restore operations. As a result restoring from a backup will restore any leaked information. Backup systems that parse AFS dumps and reconstruct AFS dumps during the restore process might or might not store and restore the leaked information. Contact the provider of your backup system. It is worth emphasizing that IBM AFS and OpenAFS volserver operations including all backup and restore operations occur in the clear. Therefore, all leaked information will be visible to passive viewers on the network segments across which volume backups and moves occur. What the salvager's "-salvagedirs" option does is force the salvager to rewrite every directory object. This has two benefits when performed by a 1.6.20 or later salvager. 1. It will build a directory file that contains no leaked information stored in the original directory file. 2. It will compact the directory to reduce fragmentation that could have resulted in directory full errors when attempting to store a filename that required more directory blocks than are available contiguously. I hope this information is helpful. Jeffrey Altman <> smime.p7s Description: S/MIME Cryptographic Signature
