Two dir's of identical ownership, but `cat > f` produces differently owned files
up vote
2
down vote
favorite
Why do myfile.txt and myotherfile.txt have different ownership?
The first directory, myhandle on my Desktop, was created using sudo chown. The second directory under /run/... was created as a networked file system by keybase.
From my ~/Desktop/myhandle:
$ ls -l ..
total 0
drwx------ 1 me root 126 Nov 23 23:10 myhandle
$ ls -la
total 0
drwx------ 1 me root 126 Nov 23 23:10 .
dr-x------ 1 me root 46 Nov 20 01:50 ..
$ cat > myfile.txt
test
$ ls -la
total 4
drwx------ 1 me root 146 Nov 23 23:11 .
dr-x------ 1 me root 46 Nov 20 01:50 ..
-rw-rw-r-- 1 me me 5 Nov 23 23:11 myfile.txt
From /run/user/1000/keybase/kbfs/private/myhandle
$ ls -l ..
total 1
drwx------ 1 me root 504 Nov 23 23:12 myhandle
$ ls -la
total 0
$ cat > myotherfile.txt
test
$ ls -la
total 1
-rw------- 1 me root 5 Nov 23 23:12 myotherfile.txt
file-permissions ubuntu-18.04 keybase
asked Nov 24 at 7:26
Diagon
431414
add a comment |
up vote
2
down vote
favorite
Why do myfile.txt and myotherfile.txt have different ownership?
The first directory, myhandle on my Desktop, was created using sudo chown. The second directory under /run/... was created as a networked file system by keybase.
From my ~/Desktop/myhandle:
$ ls -l ..
total 0
drwx------ 1 me root 126 Nov 23 23:10 myhandle
$ ls -la
total 0
drwx------ 1 me root 126 Nov 23 23:10 .
dr-x------ 1 me root 46 Nov 20 01:50 ..
$ cat > myfile.txt
test
$ ls -la
total 4
drwx------ 1 me root 146 Nov 23 23:11 .
dr-x------ 1 me root 46 Nov 20 01:50 ..
-rw-rw-r-- 1 me me 5 Nov 23 23:11 myfile.txt
From /run/user/1000/keybase/kbfs/private/myhandle
$ ls -l ..
total 1
drwx------ 1 me root 504 Nov 23 23:12 myhandle
$ ls -la
total 0
$ cat > myotherfile.txt
test
$ ls -la
total 1
-rw------- 1 me root 5 Nov 23 23:12 myotherfile.txt
file-permissions ubuntu-18.04 keybase
asked Nov 24 at 7:26
Diagon
431414
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Why do myfile.txt and myotherfile.txt have different ownership?
The first directory, myhandle on my Desktop, was created using sudo chown. The second directory under /run/... was created as a networked file system by keybase.
From my ~/Desktop/myhandle:
$ ls -l ..
total 0
drwx------ 1 me root 126 Nov 23 23:10 myhandle
$ ls -la
total 0
drwx------ 1 me root 126 Nov 23 23:10 .
dr-x------ 1 me root 46 Nov 20 01:50 ..
$ cat > myfile.txt
test
$ ls -la
total 4
drwx------ 1 me root 146 Nov 23 23:11 .
dr-x------ 1 me root 46 Nov 20 01:50 ..
-rw-rw-r-- 1 me me 5 Nov 23 23:11 myfile.txt
From /run/user/1000/keybase/kbfs/private/myhandle
$ ls -l ..
total 1
drwx------ 1 me root 504 Nov 23 23:12 myhandle
$ ls -la
total 0
$ cat > myotherfile.txt
test
$ ls -la
total 1
-rw------- 1 me root 5 Nov 23 23:12 myotherfile.txt
file-permissions ubuntu-18.04 keybase
asked Nov 24 at 7:26
Diagon
431414
Why do myfile.txt and myotherfile.txt have different ownership?
The first directory, myhandle on my Desktop, was created using sudo chown. The second directory under /run/... was created as a networked file system by keybase.
From my ~/Desktop/myhandle:
$ ls -l ..
total 0
drwx------ 1 me root 126 Nov 23 23:10 myhandle
$ ls -la
total 0
drwx------ 1 me root 126 Nov 23 23:10 .
dr-x------ 1 me root 46 Nov 20 01:50 ..
$ cat > myfile.txt
test
$ ls -la
total 4
drwx------ 1 me root 146 Nov 23 23:11 .
dr-x------ 1 me root 46 Nov 20 01:50 ..
-rw-rw-r-- 1 me me 5 Nov 23 23:11 myfile.txt
From /run/user/1000/keybase/kbfs/private/myhandle
$ ls -l ..
total 1
drwx------ 1 me root 504 Nov 23 23:12 myhandle
$ ls -la
total 0
$ cat > myotherfile.txt
test
$ ls -la
total 1
-rw------- 1 me root 5 Nov 23 23:12 myotherfile.txt
file-permissions ubuntu-18.04 keybase
file-permissions ubuntu-18.04 keybase
asked Nov 24 at 7:26
Diagon
431414
asked Nov 24 at 7:26
Diagon
431414
asked Nov 24 at 7:26
Diagon
431414
asked Nov 24 at 7:26
Diagon
431414
asked Nov 24 at 7:26
Diagon
431414
431414
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
The path component kbfs sounds like its contents could be on another filesystem (kbfs is the name of the filesystem keybase uses).
It is not unheard-of for special file systems to not adhere to common expectations about permissions.
See also an old bug in keybase where, in its filesystem, it was reporting completely different permissions than it was actually using: https://github.com/keybase/kbfs/issues/212
answered Nov 24 at 8:47
Christoph Sommer
1713
New contributor
Christoph Sommer is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Quick search reveals/run/user/1000/keybase/kbfsis indeed a mountpoint for FUSE filesystem and the relevant executable iskbfsfuse.
– Kamil Maciorowski
Nov 24 at 8:55
I think what's happening - maybe you can tell me if this is right - is that when writing to this filesystem, it is actually keybase that's doing the writing, and keybase itself is running as user myself, but group root. (Is that the way it works, that a running daemon has a user/group under which it runs?) As a result files take on that ownership.
– Diagon
Nov 24 at 9:01
Filesystems are free to report whatever permissions they want and free to use whatever logic to decide who is allowed to do what on the filesystem. Most standard file systems are sticking to established conventions here, so that the user can predict which operations will be successful - but, really, nothing stops a filesystem from telling a user "nobody can write to this file" and, in reality, allowing everybody to do so.
– Christoph Sommer
Nov 24 at 9:05
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
The path component kbfs sounds like its contents could be on another filesystem (kbfs is the name of the filesystem keybase uses).
It is not unheard-of for special file systems to not adhere to common expectations about permissions.
See also an old bug in keybase where, in its filesystem, it was reporting completely different permissions than it was actually using: https://github.com/keybase/kbfs/issues/212
answered Nov 24 at 8:47
Christoph Sommer
1713
New contributor
Christoph Sommer is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Quick search reveals/run/user/1000/keybase/kbfsis indeed a mountpoint for FUSE filesystem and the relevant executable iskbfsfuse.
– Kamil Maciorowski
Nov 24 at 8:55
I think what's happening - maybe you can tell me if this is right - is that when writing to this filesystem, it is actually keybase that's doing the writing, and keybase itself is running as user myself, but group root. (Is that the way it works, that a running daemon has a user/group under which it runs?) As a result files take on that ownership.
– Diagon
Nov 24 at 9:01
Filesystems are free to report whatever permissions they want and free to use whatever logic to decide who is allowed to do what on the filesystem. Most standard file systems are sticking to established conventions here, so that the user can predict which operations will be successful - but, really, nothing stops a filesystem from telling a user "nobody can write to this file" and, in reality, allowing everybody to do so.
– Christoph Sommer
Nov 24 at 9:05
add a comment |
up vote
2
down vote
accepted
The path component kbfs sounds like its contents could be on another filesystem (kbfs is the name of the filesystem keybase uses).
It is not unheard-of for special file systems to not adhere to common expectations about permissions.
See also an old bug in keybase where, in its filesystem, it was reporting completely different permissions than it was actually using: https://github.com/keybase/kbfs/issues/212
answered Nov 24 at 8:47
Christoph Sommer
1713
New contributor
Christoph Sommer is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Quick search reveals/run/user/1000/keybase/kbfsis indeed a mountpoint for FUSE filesystem and the relevant executable iskbfsfuse.
– Kamil Maciorowski
Nov 24 at 8:55
I think what's happening - maybe you can tell me if this is right - is that when writing to this filesystem, it is actually keybase that's doing the writing, and keybase itself is running as user myself, but group root. (Is that the way it works, that a running daemon has a user/group under which it runs?) As a result files take on that ownership.
– Diagon
Nov 24 at 9:01
Filesystems are free to report whatever permissions they want and free to use whatever logic to decide who is allowed to do what on the filesystem. Most standard file systems are sticking to established conventions here, so that the user can predict which operations will be successful - but, really, nothing stops a filesystem from telling a user "nobody can write to this file" and, in reality, allowing everybody to do so.
– Christoph Sommer
Nov 24 at 9:05
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
The path component kbfs sounds like its contents could be on another filesystem (kbfs is the name of the filesystem keybase uses).
It is not unheard-of for special file systems to not adhere to common expectations about permissions.
See also an old bug in keybase where, in its filesystem, it was reporting completely different permissions than it was actually using: https://github.com/keybase/kbfs/issues/212
answered Nov 24 at 8:47
Christoph Sommer
1713
New contributor
Christoph Sommer is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
The path component kbfs sounds like its contents could be on another filesystem (kbfs is the name of the filesystem keybase uses).
It is not unheard-of for special file systems to not adhere to common expectations about permissions.
See also an old bug in keybase where, in its filesystem, it was reporting completely different permissions than it was actually using: https://github.com/keybase/kbfs/issues/212
answered Nov 24 at 8:47
Christoph Sommer
1713
New contributor
Christoph Sommer is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered Nov 24 at 8:47
Christoph Sommer
1713
New contributor
Christoph Sommer is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered Nov 24 at 8:47
Christoph Sommer
1713
answered Nov 24 at 8:47
Christoph Sommer
1713
1713
New contributor
Christoph Sommer is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Christoph Sommer is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Christoph Sommer is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Quick search reveals/run/user/1000/keybase/kbfsis indeed a mountpoint for FUSE filesystem and the relevant executable iskbfsfuse.
– Kamil Maciorowski
Nov 24 at 8:55
I think what's happening - maybe you can tell me if this is right - is that when writing to this filesystem, it is actually keybase that's doing the writing, and keybase itself is running as user myself, but group root. (Is that the way it works, that a running daemon has a user/group under which it runs?) As a result files take on that ownership.
– Diagon
Nov 24 at 9:01
Filesystems are free to report whatever permissions they want and free to use whatever logic to decide who is allowed to do what on the filesystem. Most standard file systems are sticking to established conventions here, so that the user can predict which operations will be successful - but, really, nothing stops a filesystem from telling a user "nobody can write to this file" and, in reality, allowing everybody to do so.
– Christoph Sommer
Nov 24 at 9:05
add a comment |
Quick search reveals/run/user/1000/keybase/kbfsis indeed a mountpoint for FUSE filesystem and the relevant executable iskbfsfuse.
– Kamil Maciorowski
Nov 24 at 8:55
I think what's happening - maybe you can tell me if this is right - is that when writing to this filesystem, it is actually keybase that's doing the writing, and keybase itself is running as user myself, but group root. (Is that the way it works, that a running daemon has a user/group under which it runs?) As a result files take on that ownership.
– Diagon
Nov 24 at 9:01
Filesystems are free to report whatever permissions they want and free to use whatever logic to decide who is allowed to do what on the filesystem. Most standard file systems are sticking to established conventions here, so that the user can predict which operations will be successful - but, really, nothing stops a filesystem from telling a user "nobody can write to this file" and, in reality, allowing everybody to do so.
– Christoph Sommer
Nov 24 at 9:05
Quick search reveals
/run/user/1000/keybase/kbfs is indeed a mountpoint for FUSE filesystem and the relevant executable is kbfsfuse.– Kamil Maciorowski
Nov 24 at 8:55
Quick search reveals
/run/user/1000/keybase/kbfs is indeed a mountpoint for FUSE filesystem and the relevant executable is kbfsfuse.– Kamil Maciorowski
Nov 24 at 8:55
I think what's happening - maybe you can tell me if this is right - is that when writing to this filesystem, it is actually keybase that's doing the writing, and keybase itself is running as user myself, but group root. (Is that the way it works, that a running daemon has a user/group under which it runs?) As a result files take on that ownership.
– Diagon
Nov 24 at 9:01
I think what's happening - maybe you can tell me if this is right - is that when writing to this filesystem, it is actually keybase that's doing the writing, and keybase itself is running as user myself, but group root. (Is that the way it works, that a running daemon has a user/group under which it runs?) As a result files take on that ownership.
– Diagon
Nov 24 at 9:01
Filesystems are free to report whatever permissions they want and free to use whatever logic to decide who is allowed to do what on the filesystem. Most standard file systems are sticking to established conventions here, so that the user can predict which operations will be successful - but, really, nothing stops a filesystem from telling a user "nobody can write to this file" and, in reality, allowing everybody to do so.
– Christoph Sommer
Nov 24 at 9:05
Filesystems are free to report whatever permissions they want and free to use whatever logic to decide who is allowed to do what on the filesystem. Most standard file systems are sticking to established conventions here, so that the user can predict which operations will be successful - but, really, nothing stops a filesystem from telling a user "nobody can write to this file" and, in reality, allowing everybody to do so.
– Christoph Sommer
Nov 24 at 9:05
add a comment |
Thanks for contributing an answer to Super User!
- 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%2fsuperuser.com%2fquestions%2f1377964%2ftwo-dirs-of-identical-ownership-but-cat-f-produces-differently-owned-files%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
