Writing to /root/workspace doesn't break the files inside encrypted partition











up vote
2
down vote

favorite












I have made full disk encryption on my hard disk exactly as in this guide



https://web.archive.org/web/20180428191153/http://thesimplecomputer.info/full-disk-encryption-with-ubuntu



Partition table: GPT

Options: cryptsetup luksFormat --cipher serpent-xts-plain64 --key-size 512 --hash sha512



I have 4 encypted partitions: root,swap,home,workspace and unencrypted BIOS boot. At boot time when I type my password and when I am inside the OS all 4 partitions are mounted and unlocked. All the partitions have the same password.



Out of curiosity I locked and unmounted partition "workspace" through the ubuntu Disks app, the contents disappeared and it became like an empty partition while being viewed from Nautilus. After that I wrote a simple text file inside with some random words. I did it by opening gedit GUI, wrote some text inside then saved the file as New text file inside the locked partition. More precisely, after I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.



Then I mounted and unlocked the partition and the files inside appeared again, all of them were working and non corrupted. After that I wrote around 10 GB of files inside the encrypted partition(Did this by just copy pasting a few files that already existed inside this partition with a different name) and then unmounted and locked it again. For my surprise the text file was still there, it wasn't corrupted and contained the same words untouched.



Now my questions regarding this scenario




  1. Did this break the FDE in some way and did it create some new surface for attack? Since my root,swap and home were mounted and I wrote in the clear inside volume workspace did this somehow compromise and could lead to reveal of the password which was used in the other partitions too?


  2. As far as I red Luks header is in the beginning of each partition, when I wrote a file inside the unmounted locked partition, how didn't it become corrupted? Should that file overwrite the Luks header or parts from the encrypted files? Instead all the files were intact and I could mount and unlock again.


  3. The vice versa from question 2. When I wrote 10GB of files inside the unlocked and mounted partition shouldn't they have overwritten that unencrypted text file? Instead when I locked and unmounted it, the file withe the string was right there intact.


  4. Is the guide which I used correct or there are things not mentioned and leave me vulnerable in some way?











share|improve this question















migrated from crypto.stackexchange.com yesterday


This question came from our site for software developers, mathematicians and others interested in cryptography.











  • 2




    It's not unlikely that you simply wrote into space that's marked as empty in the encrypted partition. The filesystem doesn't particularly care about the content of empty space. But I'm not sure if this question is on-topic here.
    – Maeher
    yesterday










  • “After that I wrote a simple text file inside with a string.” What did you do exactly? Copy-paste the commands, or if you used a GUI, explain very precisely what you did. It's impossible to answer this question if we don't know what you did, and there are many things that could fit your one-sentence description.
    – Gilles
    yesterday










  • @Gilles I edited the question with clarification.
    – user64352
    yesterday










  • @Gilles After I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.
    – user64352
    yesterday















up vote
2
down vote

favorite












I have made full disk encryption on my hard disk exactly as in this guide



https://web.archive.org/web/20180428191153/http://thesimplecomputer.info/full-disk-encryption-with-ubuntu



Partition table: GPT

Options: cryptsetup luksFormat --cipher serpent-xts-plain64 --key-size 512 --hash sha512



I have 4 encypted partitions: root,swap,home,workspace and unencrypted BIOS boot. At boot time when I type my password and when I am inside the OS all 4 partitions are mounted and unlocked. All the partitions have the same password.



Out of curiosity I locked and unmounted partition "workspace" through the ubuntu Disks app, the contents disappeared and it became like an empty partition while being viewed from Nautilus. After that I wrote a simple text file inside with some random words. I did it by opening gedit GUI, wrote some text inside then saved the file as New text file inside the locked partition. More precisely, after I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.



Then I mounted and unlocked the partition and the files inside appeared again, all of them were working and non corrupted. After that I wrote around 10 GB of files inside the encrypted partition(Did this by just copy pasting a few files that already existed inside this partition with a different name) and then unmounted and locked it again. For my surprise the text file was still there, it wasn't corrupted and contained the same words untouched.



Now my questions regarding this scenario




  1. Did this break the FDE in some way and did it create some new surface for attack? Since my root,swap and home were mounted and I wrote in the clear inside volume workspace did this somehow compromise and could lead to reveal of the password which was used in the other partitions too?


  2. As far as I red Luks header is in the beginning of each partition, when I wrote a file inside the unmounted locked partition, how didn't it become corrupted? Should that file overwrite the Luks header or parts from the encrypted files? Instead all the files were intact and I could mount and unlock again.


  3. The vice versa from question 2. When I wrote 10GB of files inside the unlocked and mounted partition shouldn't they have overwritten that unencrypted text file? Instead when I locked and unmounted it, the file withe the string was right there intact.


  4. Is the guide which I used correct or there are things not mentioned and leave me vulnerable in some way?











share|improve this question















migrated from crypto.stackexchange.com yesterday


This question came from our site for software developers, mathematicians and others interested in cryptography.











  • 2




    It's not unlikely that you simply wrote into space that's marked as empty in the encrypted partition. The filesystem doesn't particularly care about the content of empty space. But I'm not sure if this question is on-topic here.
    – Maeher
    yesterday










  • “After that I wrote a simple text file inside with a string.” What did you do exactly? Copy-paste the commands, or if you used a GUI, explain very precisely what you did. It's impossible to answer this question if we don't know what you did, and there are many things that could fit your one-sentence description.
    – Gilles
    yesterday










  • @Gilles I edited the question with clarification.
    – user64352
    yesterday










  • @Gilles After I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.
    – user64352
    yesterday













up vote
2
down vote

favorite









up vote
2
down vote

favorite











I have made full disk encryption on my hard disk exactly as in this guide



https://web.archive.org/web/20180428191153/http://thesimplecomputer.info/full-disk-encryption-with-ubuntu



Partition table: GPT

Options: cryptsetup luksFormat --cipher serpent-xts-plain64 --key-size 512 --hash sha512



I have 4 encypted partitions: root,swap,home,workspace and unencrypted BIOS boot. At boot time when I type my password and when I am inside the OS all 4 partitions are mounted and unlocked. All the partitions have the same password.



Out of curiosity I locked and unmounted partition "workspace" through the ubuntu Disks app, the contents disappeared and it became like an empty partition while being viewed from Nautilus. After that I wrote a simple text file inside with some random words. I did it by opening gedit GUI, wrote some text inside then saved the file as New text file inside the locked partition. More precisely, after I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.



Then I mounted and unlocked the partition and the files inside appeared again, all of them were working and non corrupted. After that I wrote around 10 GB of files inside the encrypted partition(Did this by just copy pasting a few files that already existed inside this partition with a different name) and then unmounted and locked it again. For my surprise the text file was still there, it wasn't corrupted and contained the same words untouched.



Now my questions regarding this scenario




  1. Did this break the FDE in some way and did it create some new surface for attack? Since my root,swap and home were mounted and I wrote in the clear inside volume workspace did this somehow compromise and could lead to reveal of the password which was used in the other partitions too?


  2. As far as I red Luks header is in the beginning of each partition, when I wrote a file inside the unmounted locked partition, how didn't it become corrupted? Should that file overwrite the Luks header or parts from the encrypted files? Instead all the files were intact and I could mount and unlock again.


  3. The vice versa from question 2. When I wrote 10GB of files inside the unlocked and mounted partition shouldn't they have overwritten that unencrypted text file? Instead when I locked and unmounted it, the file withe the string was right there intact.


  4. Is the guide which I used correct or there are things not mentioned and leave me vulnerable in some way?











share|improve this question















I have made full disk encryption on my hard disk exactly as in this guide



https://web.archive.org/web/20180428191153/http://thesimplecomputer.info/full-disk-encryption-with-ubuntu



Partition table: GPT

Options: cryptsetup luksFormat --cipher serpent-xts-plain64 --key-size 512 --hash sha512



I have 4 encypted partitions: root,swap,home,workspace and unencrypted BIOS boot. At boot time when I type my password and when I am inside the OS all 4 partitions are mounted and unlocked. All the partitions have the same password.



Out of curiosity I locked and unmounted partition "workspace" through the ubuntu Disks app, the contents disappeared and it became like an empty partition while being viewed from Nautilus. After that I wrote a simple text file inside with some random words. I did it by opening gedit GUI, wrote some text inside then saved the file as New text file inside the locked partition. More precisely, after I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.



Then I mounted and unlocked the partition and the files inside appeared again, all of them were working and non corrupted. After that I wrote around 10 GB of files inside the encrypted partition(Did this by just copy pasting a few files that already existed inside this partition with a different name) and then unmounted and locked it again. For my surprise the text file was still there, it wasn't corrupted and contained the same words untouched.



Now my questions regarding this scenario




  1. Did this break the FDE in some way and did it create some new surface for attack? Since my root,swap and home were mounted and I wrote in the clear inside volume workspace did this somehow compromise and could lead to reveal of the password which was used in the other partitions too?


  2. As far as I red Luks header is in the beginning of each partition, when I wrote a file inside the unmounted locked partition, how didn't it become corrupted? Should that file overwrite the Luks header or parts from the encrypted files? Instead all the files were intact and I could mount and unlock again.


  3. The vice versa from question 2. When I wrote 10GB of files inside the unlocked and mounted partition shouldn't they have overwritten that unencrypted text file? Instead when I locked and unmounted it, the file withe the string was right there intact.


  4. Is the guide which I used correct or there are things not mentioned and leave me vulnerable in some way?








files mount disk-encryption






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited yesterday









Gilles

526k12710521579




526k12710521579










asked yesterday







user64352











migrated from crypto.stackexchange.com yesterday


This question came from our site for software developers, mathematicians and others interested in cryptography.






migrated from crypto.stackexchange.com yesterday


This question came from our site for software developers, mathematicians and others interested in cryptography.










  • 2




    It's not unlikely that you simply wrote into space that's marked as empty in the encrypted partition. The filesystem doesn't particularly care about the content of empty space. But I'm not sure if this question is on-topic here.
    – Maeher
    yesterday










  • “After that I wrote a simple text file inside with a string.” What did you do exactly? Copy-paste the commands, or if you used a GUI, explain very precisely what you did. It's impossible to answer this question if we don't know what you did, and there are many things that could fit your one-sentence description.
    – Gilles
    yesterday










  • @Gilles I edited the question with clarification.
    – user64352
    yesterday










  • @Gilles After I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.
    – user64352
    yesterday














  • 2




    It's not unlikely that you simply wrote into space that's marked as empty in the encrypted partition. The filesystem doesn't particularly care about the content of empty space. But I'm not sure if this question is on-topic here.
    – Maeher
    yesterday










  • “After that I wrote a simple text file inside with a string.” What did you do exactly? Copy-paste the commands, or if you used a GUI, explain very precisely what you did. It's impossible to answer this question if we don't know what you did, and there are many things that could fit your one-sentence description.
    – Gilles
    yesterday










  • @Gilles I edited the question with clarification.
    – user64352
    yesterday










  • @Gilles After I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.
    – user64352
    yesterday








2




2




It's not unlikely that you simply wrote into space that's marked as empty in the encrypted partition. The filesystem doesn't particularly care about the content of empty space. But I'm not sure if this question is on-topic here.
– Maeher
yesterday




It's not unlikely that you simply wrote into space that's marked as empty in the encrypted partition. The filesystem doesn't particularly care about the content of empty space. But I'm not sure if this question is on-topic here.
– Maeher
yesterday












“After that I wrote a simple text file inside with a string.” What did you do exactly? Copy-paste the commands, or if you used a GUI, explain very precisely what you did. It's impossible to answer this question if we don't know what you did, and there are many things that could fit your one-sentence description.
– Gilles
yesterday




“After that I wrote a simple text file inside with a string.” What did you do exactly? Copy-paste the commands, or if you used a GUI, explain very precisely what you did. It's impossible to answer this question if we don't know what you did, and there are many things that could fit your one-sentence description.
– Gilles
yesterday












@Gilles I edited the question with clarification.
– user64352
yesterday




@Gilles I edited the question with clarification.
– user64352
yesterday












@Gilles After I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.
– user64352
yesterday




@Gilles After I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.
– user64352
yesterday










1 Answer
1






active

oldest

votes

















up vote
1
down vote













When you “unlock” the encrypted volume, this actually does two things:




  1. The content of this encrypted volume is made available to the system as a block device. Think of a block device as a disk or partition, possibly a virtual one.

  2. This virtual disk happens to contain a filesystem, and the filesystem is mounted to the directory /root/workspace. ”Mounting” means that the filesystem becomes visible under that directory.


You unlocked the encrypted volume, then wrote a file to /root/workspace. At the point when you wrote this file, /root/workspace was an ordinary directory on the root partition, it didn't have anything mounted to it. So you just wrote a file to the root partition. It didn't affect the encrypted volume because there was no relationship between /root/workspace and the encrypted volume.



When you mounted the encrypted filesystem to /root/workspace, that hid the file that was in this directory. It didn't remove the file, it just made it temporarily inaccessible.



If you wanted to overwrite the encrypted volume, you'd have to access it directly. You can't do this directly from Gedit because it can only write to a filesystem, it can't write to a disk or to a partition directly. You could to it from the command line with something like echo BREAK IT >/dev/sda99 (sda99 is just an example). You'd need to run this as root, and to find the right name to put instead of sda99. The output of findmnt contains the right name. Obviously you should be very careful here, because if you do this it will break your encrypted volume, and if you do it on the wrong volume it is likely to make that volume unusable.



On a well-configured system, you shouldn't be able to write to a directory that's designated as a system mount point: /root/workspace should be writable by root only and you shouldn't work as root. (Note that the permissions on /root/workspace only matter when there is nothing mounted on the directory: mounting hides the contents of the directory, including the directory itself.) This way there would be no risk to accidentally save something on a different partition from the one you intended: you would get a “permission denied” error. To fix the partitions on /root/workspace, you can use the following command while /root/workspace is not mounted:



sudo chmod 755 /root/workspace; sudo chown root:root /root/workspace


Incidentally, note that /root is a very unusual place for a mount point. /media/workspace would be more usual for a volume that is mounted temporarily, and either /media/workspace or /workspace or just making it /home for a volume that's mounted all the time.



Also potentially of interest, if you've lost track whether a file is on an encrypted volume of not, here's how you can tell from the command line. (There must be a way in Nautilus as well, maybe even in the Gnome file opening dialog, but I'm not familiar with it.)



df /path/to/file
findmnt


The command df shows how much disk space is free on the volume containing /path/to/filedf stands for ”disk free“. It also shows the volume name and its mount point. Depending on your volume organization, this may be enough to tell. If it isn't, look up the volume in the output of findmnt to see if it's a subvolume of an encrypted volume.






share|improve this answer





















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489324%2fwriting-to-root-workspace-doesnt-break-the-files-inside-encrypted-partition%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown
























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    1
    down vote













    When you “unlock” the encrypted volume, this actually does two things:




    1. The content of this encrypted volume is made available to the system as a block device. Think of a block device as a disk or partition, possibly a virtual one.

    2. This virtual disk happens to contain a filesystem, and the filesystem is mounted to the directory /root/workspace. ”Mounting” means that the filesystem becomes visible under that directory.


    You unlocked the encrypted volume, then wrote a file to /root/workspace. At the point when you wrote this file, /root/workspace was an ordinary directory on the root partition, it didn't have anything mounted to it. So you just wrote a file to the root partition. It didn't affect the encrypted volume because there was no relationship between /root/workspace and the encrypted volume.



    When you mounted the encrypted filesystem to /root/workspace, that hid the file that was in this directory. It didn't remove the file, it just made it temporarily inaccessible.



    If you wanted to overwrite the encrypted volume, you'd have to access it directly. You can't do this directly from Gedit because it can only write to a filesystem, it can't write to a disk or to a partition directly. You could to it from the command line with something like echo BREAK IT >/dev/sda99 (sda99 is just an example). You'd need to run this as root, and to find the right name to put instead of sda99. The output of findmnt contains the right name. Obviously you should be very careful here, because if you do this it will break your encrypted volume, and if you do it on the wrong volume it is likely to make that volume unusable.



    On a well-configured system, you shouldn't be able to write to a directory that's designated as a system mount point: /root/workspace should be writable by root only and you shouldn't work as root. (Note that the permissions on /root/workspace only matter when there is nothing mounted on the directory: mounting hides the contents of the directory, including the directory itself.) This way there would be no risk to accidentally save something on a different partition from the one you intended: you would get a “permission denied” error. To fix the partitions on /root/workspace, you can use the following command while /root/workspace is not mounted:



    sudo chmod 755 /root/workspace; sudo chown root:root /root/workspace


    Incidentally, note that /root is a very unusual place for a mount point. /media/workspace would be more usual for a volume that is mounted temporarily, and either /media/workspace or /workspace or just making it /home for a volume that's mounted all the time.



    Also potentially of interest, if you've lost track whether a file is on an encrypted volume of not, here's how you can tell from the command line. (There must be a way in Nautilus as well, maybe even in the Gnome file opening dialog, but I'm not familiar with it.)



    df /path/to/file
    findmnt


    The command df shows how much disk space is free on the volume containing /path/to/filedf stands for ”disk free“. It also shows the volume name and its mount point. Depending on your volume organization, this may be enough to tell. If it isn't, look up the volume in the output of findmnt to see if it's a subvolume of an encrypted volume.






    share|improve this answer

























      up vote
      1
      down vote













      When you “unlock” the encrypted volume, this actually does two things:




      1. The content of this encrypted volume is made available to the system as a block device. Think of a block device as a disk or partition, possibly a virtual one.

      2. This virtual disk happens to contain a filesystem, and the filesystem is mounted to the directory /root/workspace. ”Mounting” means that the filesystem becomes visible under that directory.


      You unlocked the encrypted volume, then wrote a file to /root/workspace. At the point when you wrote this file, /root/workspace was an ordinary directory on the root partition, it didn't have anything mounted to it. So you just wrote a file to the root partition. It didn't affect the encrypted volume because there was no relationship between /root/workspace and the encrypted volume.



      When you mounted the encrypted filesystem to /root/workspace, that hid the file that was in this directory. It didn't remove the file, it just made it temporarily inaccessible.



      If you wanted to overwrite the encrypted volume, you'd have to access it directly. You can't do this directly from Gedit because it can only write to a filesystem, it can't write to a disk or to a partition directly. You could to it from the command line with something like echo BREAK IT >/dev/sda99 (sda99 is just an example). You'd need to run this as root, and to find the right name to put instead of sda99. The output of findmnt contains the right name. Obviously you should be very careful here, because if you do this it will break your encrypted volume, and if you do it on the wrong volume it is likely to make that volume unusable.



      On a well-configured system, you shouldn't be able to write to a directory that's designated as a system mount point: /root/workspace should be writable by root only and you shouldn't work as root. (Note that the permissions on /root/workspace only matter when there is nothing mounted on the directory: mounting hides the contents of the directory, including the directory itself.) This way there would be no risk to accidentally save something on a different partition from the one you intended: you would get a “permission denied” error. To fix the partitions on /root/workspace, you can use the following command while /root/workspace is not mounted:



      sudo chmod 755 /root/workspace; sudo chown root:root /root/workspace


      Incidentally, note that /root is a very unusual place for a mount point. /media/workspace would be more usual for a volume that is mounted temporarily, and either /media/workspace or /workspace or just making it /home for a volume that's mounted all the time.



      Also potentially of interest, if you've lost track whether a file is on an encrypted volume of not, here's how you can tell from the command line. (There must be a way in Nautilus as well, maybe even in the Gnome file opening dialog, but I'm not familiar with it.)



      df /path/to/file
      findmnt


      The command df shows how much disk space is free on the volume containing /path/to/filedf stands for ”disk free“. It also shows the volume name and its mount point. Depending on your volume organization, this may be enough to tell. If it isn't, look up the volume in the output of findmnt to see if it's a subvolume of an encrypted volume.






      share|improve this answer























        up vote
        1
        down vote










        up vote
        1
        down vote









        When you “unlock” the encrypted volume, this actually does two things:




        1. The content of this encrypted volume is made available to the system as a block device. Think of a block device as a disk or partition, possibly a virtual one.

        2. This virtual disk happens to contain a filesystem, and the filesystem is mounted to the directory /root/workspace. ”Mounting” means that the filesystem becomes visible under that directory.


        You unlocked the encrypted volume, then wrote a file to /root/workspace. At the point when you wrote this file, /root/workspace was an ordinary directory on the root partition, it didn't have anything mounted to it. So you just wrote a file to the root partition. It didn't affect the encrypted volume because there was no relationship between /root/workspace and the encrypted volume.



        When you mounted the encrypted filesystem to /root/workspace, that hid the file that was in this directory. It didn't remove the file, it just made it temporarily inaccessible.



        If you wanted to overwrite the encrypted volume, you'd have to access it directly. You can't do this directly from Gedit because it can only write to a filesystem, it can't write to a disk or to a partition directly. You could to it from the command line with something like echo BREAK IT >/dev/sda99 (sda99 is just an example). You'd need to run this as root, and to find the right name to put instead of sda99. The output of findmnt contains the right name. Obviously you should be very careful here, because if you do this it will break your encrypted volume, and if you do it on the wrong volume it is likely to make that volume unusable.



        On a well-configured system, you shouldn't be able to write to a directory that's designated as a system mount point: /root/workspace should be writable by root only and you shouldn't work as root. (Note that the permissions on /root/workspace only matter when there is nothing mounted on the directory: mounting hides the contents of the directory, including the directory itself.) This way there would be no risk to accidentally save something on a different partition from the one you intended: you would get a “permission denied” error. To fix the partitions on /root/workspace, you can use the following command while /root/workspace is not mounted:



        sudo chmod 755 /root/workspace; sudo chown root:root /root/workspace


        Incidentally, note that /root is a very unusual place for a mount point. /media/workspace would be more usual for a volume that is mounted temporarily, and either /media/workspace or /workspace or just making it /home for a volume that's mounted all the time.



        Also potentially of interest, if you've lost track whether a file is on an encrypted volume of not, here's how you can tell from the command line. (There must be a way in Nautilus as well, maybe even in the Gnome file opening dialog, but I'm not familiar with it.)



        df /path/to/file
        findmnt


        The command df shows how much disk space is free on the volume containing /path/to/filedf stands for ”disk free“. It also shows the volume name and its mount point. Depending on your volume organization, this may be enough to tell. If it isn't, look up the volume in the output of findmnt to see if it's a subvolume of an encrypted volume.






        share|improve this answer












        When you “unlock” the encrypted volume, this actually does two things:




        1. The content of this encrypted volume is made available to the system as a block device. Think of a block device as a disk or partition, possibly a virtual one.

        2. This virtual disk happens to contain a filesystem, and the filesystem is mounted to the directory /root/workspace. ”Mounting” means that the filesystem becomes visible under that directory.


        You unlocked the encrypted volume, then wrote a file to /root/workspace. At the point when you wrote this file, /root/workspace was an ordinary directory on the root partition, it didn't have anything mounted to it. So you just wrote a file to the root partition. It didn't affect the encrypted volume because there was no relationship between /root/workspace and the encrypted volume.



        When you mounted the encrypted filesystem to /root/workspace, that hid the file that was in this directory. It didn't remove the file, it just made it temporarily inaccessible.



        If you wanted to overwrite the encrypted volume, you'd have to access it directly. You can't do this directly from Gedit because it can only write to a filesystem, it can't write to a disk or to a partition directly. You could to it from the command line with something like echo BREAK IT >/dev/sda99 (sda99 is just an example). You'd need to run this as root, and to find the right name to put instead of sda99. The output of findmnt contains the right name. Obviously you should be very careful here, because if you do this it will break your encrypted volume, and if you do it on the wrong volume it is likely to make that volume unusable.



        On a well-configured system, you shouldn't be able to write to a directory that's designated as a system mount point: /root/workspace should be writable by root only and you shouldn't work as root. (Note that the permissions on /root/workspace only matter when there is nothing mounted on the directory: mounting hides the contents of the directory, including the directory itself.) This way there would be no risk to accidentally save something on a different partition from the one you intended: you would get a “permission denied” error. To fix the partitions on /root/workspace, you can use the following command while /root/workspace is not mounted:



        sudo chmod 755 /root/workspace; sudo chown root:root /root/workspace


        Incidentally, note that /root is a very unusual place for a mount point. /media/workspace would be more usual for a volume that is mounted temporarily, and either /media/workspace or /workspace or just making it /home for a volume that's mounted all the time.



        Also potentially of interest, if you've lost track whether a file is on an encrypted volume of not, here's how you can tell from the command line. (There must be a way in Nautilus as well, maybe even in the Gnome file opening dialog, but I'm not familiar with it.)



        df /path/to/file
        findmnt


        The command df shows how much disk space is free on the volume containing /path/to/filedf stands for ”disk free“. It also shows the volume name and its mount point. Depending on your volume organization, this may be enough to tell. If it isn't, look up the volume in the output of findmnt to see if it's a subvolume of an encrypted volume.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered yesterday









        Gilles

        526k12710521579




        526k12710521579






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f489324%2fwriting-to-root-workspace-doesnt-break-the-files-inside-encrypted-partition%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Accessing regular linux commands in Huawei's Dopra Linux

            Can't connect RFCOMM socket: Host is down

            Kernel panic - not syncing: Fatal Exception in Interrupt