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
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?
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.
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.
Is the guide which I used correct or there are things not mentioned and leave me vulnerable in some way?
files mount disk-encryption
migrated from crypto.stackexchange.com yesterday
This question came from our site for software developers, mathematicians and others interested in cryptography.
add a comment |
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
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?
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.
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.
Is the guide which I used correct or there are things not mentioned and leave me vulnerable in some way?
files mount disk-encryption
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
add a comment |
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
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?
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.
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.
Is the guide which I used correct or there are things not mentioned and leave me vulnerable in some way?
files mount disk-encryption
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
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?
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.
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.
Is the guide which I used correct or there are things not mentioned and leave me vulnerable in some way?
files mount disk-encryption
files mount disk-encryption
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
add a comment |
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
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
When you “unlock” the encrypted volume, this actually does two things:
- 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.
- 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/file
— df
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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:
- 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.
- 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/file
— df
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.
add a comment |
up vote
1
down vote
When you “unlock” the encrypted volume, this actually does two things:
- 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.
- 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/file
— df
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.
add a comment |
up vote
1
down vote
up vote
1
down vote
When you “unlock” the encrypted volume, this actually does two things:
- 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.
- 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/file
— df
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.
When you “unlock” the encrypted volume, this actually does two things:
- 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.
- 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/file
— df
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.
answered yesterday
Gilles
526k12710521579
526k12710521579
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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