You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, g_process.cwdis of type dentry, meaning that it always refer to a fixed path until fchdir changes that, even in presence of rename or unlink calls. However, in POSIX the current working directory is based on inodes. That said, probably unlikely in gramine that somebody would stumble over scenarios when the two behaviours diverge?
Steps to reproduce
Change the current directory with a rename and then create a new file: The new file should be associated with the renamed directory, not the current one (or more precisely, currently will fail as this path doesn't exist anymore?). Full disclosure, i didn't experimentally validate this but in discussion with Dmitrii (@dimakuv) we agreed there is a bug here and these kind of stuff would lead to divergence to POSIX.
(alternate scenario would be that cwd is unlinked and recreated, in which case no file created from this process without call to fchdir should be visible in the filesystem directory/namespace
The text was updated successfully, but these errors were encountered:
mkow
changed the title
[LibOS] process current working directory is path-based instead of inode-based.
[LibOS] process current working directory is path-based instead of inode-based
May 16, 2024
Description of the problem
Currently,
g_process.cwd
is of typedentry
, meaning that it always refer to a fixed path untilfchdir
changes that, even in presence ofrename
orunlink
calls. However, in POSIX the current working directory is based on inodes. That said, probably unlikely in gramine that somebody would stumble over scenarios when the two behaviours diverge?Steps to reproduce
Change the current directory with a
rename
and then create a new file: The new file should be associated with the renamed directory, not the current one (or more precisely, currently will fail as this path doesn't exist anymore?). Full disclosure, i didn't experimentally validate this but in discussion with Dmitrii (@dimakuv) we agreed there is a bug here and these kind of stuff would lead to divergence to POSIX.(alternate scenario would be that cwd is unlinked and recreated, in which case no file created from this process without call to
fchdir
should be visible in the filesystem directory/namespaceGramine commit hash
80377ca
The text was updated successfully, but these errors were encountered: