Missing check for plaintextnames in many FUSE callbacks #174
Comments
|
On the first sight this affects the following functions:
|
slackner
added a commit
to slackner/gocryptfs
that referenced
this issue
Nov 28, 2017
In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. We should not attempt to read the directory IV or to create special .name files. Partially fixes rfjakob#174
slackner
added a commit
to slackner/gocryptfs
that referenced
this issue
Nov 28, 2017
In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. We should not attempt to delete any .name files. Partially fixes rfjakob#174
slackner
added a commit
to slackner/gocryptfs
that referenced
this issue
Nov 28, 2017
In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. We should not attempt to delete any .name files. Partially fixes rfjakob#174
rfjakob
pushed a commit
that referenced
this issue
Nov 28, 2017
In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. We should not attempt to delete any .name files. Partially fixes #174
|
I fear this one was closed a bit too early. Mknod and Unlink are fixed now, but there might be three other functions affected by the same problem. Should I open new bugs for them? |
|
Was auto-closed through the commit message i guess, just re-open it
…On Nov 28, 2017 10:32, "slackner" ***@***.***> wrote:
I fear this one was closed a bit too early. Mknod and Unlink are fixed
now, but there might be three other functions affected by the same problem.
Should I open new bugs for them?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#174 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARgf09xj-u5Cg9j2Kw71xfQOO8meFifks5s69MegaJpZM4QqRkd>
.
|
|
I would, but apparently I don't have permission to reopen myself. |
|
Hmm will check if i can allow that somehow |
slackner
added a commit
to slackner/gocryptfs
that referenced
this issue
Dec 12, 2017
In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. rfjakob#174
rfjakob
pushed a commit
that referenced
this issue
Dec 25, 2017
In PlaintextNames mode the "gocryptfs.longname." prefix does not have any special meaning. #174
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce:
-plaintextnamestouch gocryptfs.longname.XXXThis fails with the error
No such file or directory, but should actually succeed. The problem is that many FUSE calls do not explicitly check ifplaintextnamesis set.The text was updated successfully, but these errors were encountered: