[vim/vim] Write permissions seem to be determined by Unix permissions (Issue #10501)
kaymvoit
Steps to reproduce
This was observed in a SpectrumScale storage with CentOS.
Vim warns of a read only file, for a file with mode 0000 despite GPFS ACL via NFSv4 ACLs grants full access.
- Create file with mode 0000
- Grand full access via (NFSv4) ACL
- Open file and read warning about readonly file
- Try to save, encounter E45: 'readonly' optin is set
- Override with !, save successfully
(This came up due to the fact that the storage does not seem to set Unix permission on files that inherited permissions when they were created via CIFS, but only ACLs).
Expected behaviour
Vim determines actual status of writability.
Python's f.writeable() is able to determine the status correctly, so I assume the information is more or less trivially there.
Version of Vim
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 13 2020 16:13:17) Included patches: 1-207, 209-629
Environment
CentOS Linux release 7.9.2009 (Core)
TERM=xterm-256color
zsh 5.0.2 (x86_64-redhat-linux-gnu)
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> ### Steps to reproduce
>
> This was observed in a SpectrumScale storage with CentOS.
> Vim warns of a read only file, for a file with mode 0000 despite GPFS
> ACL via NFSv4 ACLs grants full access.
>
> 2. Grand full access via (NFSv4) ACL
> 3. Open file and read warning about readonly file
> 4. Try to save, encounter E45: 'readonly' optin is set
> 5. Override with !, save successfully
>
> (This came up due to the fact that the storage does not seem to set Unix permission on files that inherited permissions when they were created via CIFS, but only ACLs).
>
>
> Vim determines actual status of writability.
>
> Python's `f.writeable()` is able to determine the status correctly, so I assume the information is more or less trivially there.
>
>
> VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 13 2020 16:13:17) Included patches: 1-207, 209-629
>
>
> CentOS Linux release 7.9.2009 (Core)
see whether writing is possible.
The ACL methods are generally system specific. It probably requires
some configure check, code changes, using a library, etc. Not trivial.
I don't understand why systems don't provide the correct mode bits, so
that it's not up to each invididual application to implement the ACL
stuff.
--
Have you heard about the new Barbie doll? It's called Divorce
Barbie. It comes with most of Ken's stuff.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gary Johnson
> Steps to reproduce
>
> This was observed in a SpectrumScale storage with CentOS.
> Vim warns of a read only file, for a file with mode 0000 despite GPFS ACL via
> NFSv4 ACLs grants full access.
>
> 2. Grand full access via (NFSv4) ACL
> 3. Open file and read warning about readonly file
> 4. Try to save, encounter E45: 'readonly' optin is set
> 5. Override with !, save successfully
> (This came up due to the fact that the storage does not seem to set Unix
> permission on files that inherited permissions when they were created via CIFS,
> but only ACLs).
>
> Expected behaviour
>
> Vim determines actual status of writability.
>
> Python's f.writeable() is able to determine the status correctly, so I assume
> the information is more or less trivially there.
>
> Version of Vim
>
> VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 13 2020 16:13:17) Included
> patches: 1-207, 209-629
>
> Environment
>
> CentOS Linux release 7.9.2009 (Core)
> TERM=xterm-256color
> zsh 5.0.2 (x86_64-redhat-linux-gnu)
>
> Logs and stack traces
>
> No response
>
that together they set an upper limit on file access. That is,
a user's access is determined by the maximum granted by the two
mechanisms. So, if a file has mode 0000, nobody has permission to
read, write or execute it, regardless of the ACL.
Here is a citation from one reference:
POSIX Access Control Lists on Linux
https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html
Therefore, the meaning of the group class permissions is
redefined: under their new semantics, they represent an
upper bound of the permissions that any entry in the group
class will grant.
Regards,
Gary
kaymvoit
The ACL methods are generally system specific. It probably requires some configure check, code changes, using a library, etc. Not trivial.
I have now also written this small C program, which is also able to tell the difference correctly:
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
if(access(argv[1], W_OK) == 0) {
printf("%s writeable\n", argv[1]);
return 0;
} else {
printf("%s not writeable\n", argv[1]);
return 1;
}
}
I don't understand why systems don't provide the correct mode bits, so
that it's not up to each invididual application to implement the ACL
stuff.
In principle I agree with you, and I have asked our system partner to file that as an issue with IBM. However, there are situation that cannot be modeled with mode bits, e.g. multiple user based permissions, so I have kind of settled with this a s a "nice-to-have" from IBM, not not a deal breaker. Funny think is that mode bits ARE set when explicitly setting the permissions via CIFS instead of inheriting them, but that is completely OT.
Anyway, thinking about it, the question is probably what the read-only warning from vim is really supposed to mean. Since there is :w!, it cannot be meant es "you definitely cannot write here!" anyway, right? In the minimum interpretation is is just "there is no write bit for you, are you sure you are supposed to write here?" (which would be especially relevant for root).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > The ACL methods are generally system specific. It probably requires some configure check, code changes, using a library, etc. Not trivial.
>
> I have now also written this small C program, which is also able to tell the difference correctly:
> ```
> #include <stdio.h>
> #include <unistd.h>
>
> int main(int argc, char *argv[]) {
> if(access(argv[1], W_OK) == 0) {
> printf("%s writeable\n", argv[1]);
> return 0;
> } else {
> printf("%s not writeable\n", argv[1]);
> return 1;
> }
> }
>
> ```
result of access():
if (
# ifdef UNIX
!(perm & 0222) ||
# endif
mch_access((char *)fname, W_OK))
file_readonly = TRUE;
> I don't understand why systems don't provide the correct mode bits, so
> that it's not up to each invididual application to implement the ACL
> stuff.
>
> In principle I agree with you, and I have asked our system partner to
> file that as an issue with IBM. However, there are situation that
> cannot be modeled with mode bits, e.g. multiple user based
> permissions, so I have kind of settled with this a s a "nice-to-have"
> from IBM, not not a deal breaker. Funny think is that mode bits ARE
> set when explicitly setting the permissions via CIFS instead of
> inheriting them, but that is completely OT.
>
> Anyway, thinking about it, the question is probably what the read-only
> warning from vim is really supposed to mean. Since there is :w!, it
> cannot be meant es "you definitely cannot write here!" anyway, right?
> In the minimum interpretation is is just "there is no write bit for
> you, are you sure you are supposed to write here?" (which would be
> especially relevant for root).
possible to write the changes. For this it's better to assume readonly
even when writing is possible when you actually try it. A second reason
is to intentionally mark a buffer as readonly, to make it difficult to
write and avoid accidental writes.
--
CUSTOMER: Well, can you hang around a couple of minutes? He won't be
long.
MORTICIAN: Naaah, I got to go on to Robinson's -- they've lost nine today.
CUSTOMER: Well, when is your next round?
MORTICIAN: Thursday.
DEAD PERSON: I think I'll go for a walk.
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
vim-dev ML
> Steps to reproduce
>
> This was observed in a SpectrumScale storage with CentOS.
> Vim warns of a read only file, for a file with mode 0000 despite GPFS ACL via
> NFSv4 ACLs grants full access.
>
> 2. Grand full access via (NFSv4) ACL
> 3. Open file and read warning about readonly file
> 4. Try to save, encounter E45: 'readonly' optin is set
> 5. Override with !, save successfully
>
> (This came up due to the fact that the storage does not seem to set Unix
> permission on files that inherited permissions when they were created via CIFS,
> but only ACLs).
>
> Expected behaviour
>
> Vim determines actual status of writability.
>
> Python's f.writeable() is able to determine the status correctly, so I assume
> the information is more or less trivially there.
>
> Version of Vim
>
> VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 13 2020 16:13:17) Included
> patches: 1-207, 209-629
>
> Environment
>
> CentOS Linux release 7.9.2009 (Core)
> TERM=xterm-256color
> zsh 5.0.2 (x86_64-redhat-linux-gnu)
>
> Logs and stack traces
>
> No response
>
that together they set an upper limit on file access. That is,
a user's access is determined by the maximum granted by the two
mechanisms. So, if a file has mode 0000, nobody has permission to
read, write or execute it, regardless of the ACL.
Here is a citation from one reference:
POSIX Access Control Lists on Linux
https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html
Therefore, the meaning of the group class permissions is
redefined: under their new semantics, they represent an
upper bound of the permissions that any entry in the group
class will grant.
Regards,
Gary
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
kvoit
This is true for Posix ACL, but apparently not for NFSv4 ACL, which this is about.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
JustAShoeMaker
I would have second the motion. I (and my researchers) see this behavior on NSFv4 file systems as well (ours is AcLOnly and not mixed with Posix. Under it all is GPFS).
It flags a file as read only, require a ! to bypass. But is really false. Nano edits files without complaint.
Other VIM nuances related to ACLs
- Oddly,
mmeditacldoes not create the flag (and it uses the default editor. In my case VIM) - Exported share to Windows works fine with GVIM actually. No write warning.
- In mixed environments (where it is not AclOnly, but chmodding is allowed via CLI) the "updated" file of course changes ownerships and perms (since VIM deletes and saves as new really with a write)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
WorksAtAUni
It is annoying. It trips up other Linux utils and tools as well to be fair. cp will warn and still copy the file unless you use the --preserve=xattr flag
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.