9:54 a.m.
Hi, all
Suppose that in a FC6 system there are two users, user01 and user02. Both are
members of the group users, which is their primary group. They're not members
of the group root. There is a directory named /test:
drwxrwx--- 2 root users 4096 Dez 26 12:42 test/
In this directory, there is a file named file.txt:
-rw-r----- 1 user01 root 90 Dez 26 12:43 file.txt
user02, as expected, is not able to read nor modify the contents of this file,
as he does not have read nor write permissions on it. However, he can delete
the file, because he has write permissions on /test, once he's member of the
group users.
However, if user02 opens file.txt in VIM, edit it and then save it with :w!,
the file is modified, saved, and its ownership is altered to user02:users.
How can this happen?? How can VIM alter the ownership and write to this file,
if user02 is not it's owner and have no permissions on it? user02 can't do
that using chown, chmod nor chgrp, but using VIM he can?!
Thanks,
Marcelo
10:46 a.m.
Em Terça 26 Dezembro 2006 12:54, Marcelo Magno T. Sales escreveu:
Hi, all
Suppose that in a FC6 system there are two users, user01 and user02. Both
are members of the group users, which is their primary group. They're not
members of the group root. There is a directory named /test:
drwxrwx--- 2 root users 4096 Dez 26 12:42 test/
In this directory, there is a file named file.txt:
-rw-r----- 1 user01 root 90 Dez 26 12:43 file.txt
user02, as expected, is not able to read nor modify the contents of this
file, as he does not have read nor write permissions on it. However, he can
delete the file, because he has write permissions on /test, once he's
member of the group users.
However, if user02 opens file.txt in VIM, edit it and then save it with
:w!, the file is modified, saved, and its ownership is altered to
user02:users. How can this happen?? How can VIM alter the ownership and
write to this file, if user02 is not it's owner and have no permissions on
it? user02 can't do that using chown, chmod nor chgrp, but using VIM he
can?!
Never mind. VIM must be removing the existing file and creating another one
with the same name, which it has permission to do. It does not effective
change the existing file, it just replaces it.
[]'s
Marcelo
1:25 a.m.
On 26Dec2006 13:46, Marcelo Magno T. Sales <marcelo.sales(a)sefaz.pe.gov.br> wrote:
| Em Ter?a 26 Dezembro 2006 12:54, Marcelo Magno T. Sales escreveu:
[...]
| > user02, as expected, is not able to read nor modify the contents of this
| > file, as he does not have read nor write permissions on it. However, he can
| > delete the file, because he has write permissions on /test, once he's
| > member of the group users.
| > However, if user02 opens file.txt in VIM, edit it and then save it with
| > :w!, the file is modified, saved, and its ownership is altered to
| > user02:users. How can this happen?? How can VIM alter the ownership and
| > write to this file, if user02 is not it's owner and have no permissions on
| > it? user02 can't do that using chown, chmod nor chgrp, but using VIM he
| > can?!
|
| Never mind. VIM must be removing the existing file and creating another one
| with the same name, which it has permission to do. It does not effective
| change the existing file, it just replaces it.
Yep. Does this annoy you as much as it does me?
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
Anyone who values temporary safety over personal liberty, deserves neither
liberty nor safety. - Ben Franklin, paraphrased due to bad memory
5:54 a.m.
Em Quarta 27 Dezembro 2006 04:25, Cameron Simpson escreveu:
On 26Dec2006 13:46, Marcelo Magno T. Sales
<marcelo.sales(a)sefaz.pe.gov.br>
wrote:
| Em Ter?a 26 Dezembro 2006 12:54, Marcelo Magno T. Sales escreveu:
[...]
| > user02, as expected, is not able to read nor modify the contents of
| > this file, as he does not have read nor write permissions on it.
| > However, he can delete the file, because he has write permissions on
| > /test, once he's member of the group users.
| > However, if user02 opens file.txt in VIM, edit it and then save it with
| >
| > :w!, the file is modified, saved, and its ownership is altered to
| >
| > user02:users. How can this happen?? How can VIM alter the ownership and
| > write to this file, if user02 is not it's owner and have no permissions
| > on it? user02 can't do that using chown, chmod nor chgrp, but using VIM
| > he can?!
|
| Never mind. VIM must be removing the existing file and creating another
| one with the same name, which it has permission to do. It does not
| effectively change the existing file, it just replaces it.
Yep. Does this annoy you as much as it does me?
Yes, it does :)
[]'s
Marcelo
7:40 a.m.
Marcelo Magno T. Sales wrote:
Em Quarta 27 Dezembro 2006 04:25, Cameron Simpson escreveu:
> On 26Dec2006 13:46, Marcelo Magno T. Sales <marcelo.sales(a)sefaz.pe.gov.br>
wrote:
> | Em Ter?a 26 Dezembro 2006 12:54, Marcelo Magno T. Sales escreveu:
>
> [...]
>
> | > user02, as expected, is not able to read nor modify the contents of
> | > this file, as he does not have read nor write permissions on it.
> | > However, he can delete the file, because he has write permissions on
> | > /test, once he's member of the group users.
> | > However, if user02 opens file.txt in VIM, edit it and then save it with
> | >
> | > :w!, the file is modified, saved, and its ownership is altered to
> | >
> | > user02:users. How can this happen?? How can VIM alter the ownership and
> | > write to this file, if user02 is not it's owner and have no permissions
> | > on it? user02 can't do that using chown, chmod nor chgrp, but using VIM
> | > he can?!
> |
> | Never mind. VIM must be removing the existing file and creating another
> | one with the same name, which it has permission to do. It does not
> | effectively change the existing file, it just replaces it.
>
> Yep. Does this annoy you as much as it does me?
Yes, it does :)
While I'd expect an editor to normally write back to the original
file to maintain symlinks, ownership and modes in the case where
the file is writable, this sounds exactly right and what the
user would do manually himself in case write access is denied
and the user has issued the :w! directive. Without the '!' it
should give a 'file is read-only' error.
Set the sticky bit on the directory if you don't want people
who don't have write permission on the file to be able to delete
it. Then they will be forced to save under a different name.
--
Les Mikesell
lesmikesell(a)gmail.com
11:08 a.m.
Les Mikesell wrote:
Marcelo Magno T. Sales wrote:
> Em Quarta 27 Dezembro 2006 04:25, Cameron Simpson escreveu:
>> | Never mind. VIM must be removing the existing file and creating
>> another
>> | one with the same name, which it has permission to do. It does not
>> | effectively change the existing file, it just replaces it.
>>
>> Yep. Does this annoy you as much as it does me?
>
> Yes, it does :)
While I'd expect an editor to normally write back to the original
file to maintain symlinks, ownership and modes in the case where
the file is writable, this sounds exactly right and what the
user would do manually himself in case write access is denied
and the user has issued the :w! directive. Without the '!' it
should give a 'file is read-only' error.
Set the sticky bit on the directory if you don't want people
who don't have write permission on the file to be able to delete
it. Then they will be forced to save under a different name.
Symlinks are maintained as long as the name is the same. Hard links
are another story. I have seen a lot of editors and word processors
that use the write to a new file, and then rename/delete the
original file. It tends to protect your work - the original file is
there in case something goes wrong during the same process. That
way, the worst you lose is the current edits. But as you have
noticed, it does not work out as well when editing shared files.
Mikkel
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
1:17 p.m.
Mikkel L. Ellertson wrote:
.... But as you have
noticed, it does not work out as well when editing shared files.
Oddly perhaps, Unix has never really provided shared writeable files.
Perhaps there are good theoretical reasons for it; perhaps it was just
one of those simplifying assumptions that Unix was born with, I don't know.
That's why access to shared writeable resources are controlled by a
server, like CVS or svn or mysql. It's why you don't print using cat >
/dev/lpr.
People seem to want to do things like this--they keep asking for
applications to mediate between users editing the same file, like
Windows does it, but I wonder if it's such a great idea.
<Joe
2:56 p.m.
On Tue, 2007-01-02 at 14:17 -0500, Joe Smith wrote:
Oddly perhaps, Unix has never really provided shared writeable files.
Perhaps there are good theoretical reasons for it; perhaps it was just
one of those simplifying assumptions that Unix was born with, I don't
know.
Though I notice that VIM does seem to manage that well enough. If you
open the same file on two different computers, you can edit on both of
them in turn. You can't edit at the same time, though. And I couldn't
see a way of that being practical, anyway. Imagine the mess of two
authors trying to retype the same paragraph at the same time.
--
(Currently testing FC5, but still running FC4, if that's important.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
4:40 p.m.
On Tue, 2007-01-02 at 14:17 -0500, Joe Smith wrote:
Mikkel L. Ellertson wrote:
> .... But as you have
> noticed, it does not work out as well when editing shared files.
Oddly perhaps, Unix has never really provided shared writeable files.
What? If you have write permission you can write.
Perhaps there are good theoretical reasons for it; perhaps it was
just
one of those simplifying assumptions that Unix was born with, I don't know.
Initially there was no file locking and the only really atomic
operation was creating a file or making a hard link to an existing
file. Later, about a dozen different file locking methods were
added and the applications never really converged on how to do
it across versions and network mounts. Plus, a lot of stuff depends
on the unix filesystem semantics where you can create a new file
under a temporary name, rename it, which atomically replaces the
old name, and processes that opened before the rename continue to
see the old file contents while subsequent opens get the new contents.
People seem to want to do things like this--they keep asking for
applications to mediate between users editing the same file, like
Windows does it, but I wonder if it's such a great idea.
You can do this if you only run one OS version and don't use
networks to access the file - but a dedicated server process to
provide the arbitration is usually better anyway.
--
Les Mikesell
lesmikesell(a)gmail.com
8:21 p.m.
Les Mikesell wrote:
On Tue, 2007-01-02 at 14:17 -0500, Joe Smith wrote:
> Mikkel L. Ellertson wrote:
>> .... But as you have
>> noticed, it does not work out as well when editing shared files.
> Oddly perhaps, Unix has never really provided shared writeable files.
What? If you have write permission you can write.
But two processes writing to the same file at the same time gives you
what? Probably not what you want.
I don't mean literally Unix can't do it, I only meant that Unix never
really supported it with a standard API that worked well enough to be
widely accepted and handled all the complicated corner cases that rear
up when two users want to naively "share a file".
> Perhaps there are good theoretical reasons for it; perhaps it was
just
> one of those simplifying assumptions that Unix was born with, I don't know.
Initially there was no file locking and the only really atomic
operation was creating a file or making a hard link to an existing
file. Later, about a dozen different file locking methods were
added and the applications never really converged on how to do
it across versions and network mounts. Plus, a lot of stuff depends
on the unix filesystem semantics ...
Thanks for making my point with real facts ;-)
Sorry everybody: drifting off-topic and talking stuff that I know just
well enough to make an ass of myself, so I'm going to shut up right
about... now.
<Joe
2:56 a.m.
On Tue, 2007-01-02 at 14:17 -0500, Joe Smith wrote:
Mikkel L. Ellertson wrote:
> .... But as you have
> noticed, it does not work out as well when editing shared files.
Oddly perhaps, Unix has never really provided shared writeable files.
Perhaps there are good theoretical reasons for it; perhaps it was just
one of those simplifying assumptions that Unix was born with, I don't know.
That's why access to shared writeable resources are controlled by a
server, like CVS or svn or mysql. It's why you don't print using cat >
/dev/lpr.
People seem to want to do things like this--they keep asking for
applications to mediate between users editing the same file, like
Windows does it, but I wonder if it's such a great idea.
<Joe
Widnows doesn't do it either, at least not up to XP. There are RCS
systems that can run on windows to mediate such development tasks, but
natively windows suffers from the same issues of time lag, priority
determination, and choosing the latest or most correct of corrections.
View how a Wiki evolves to begin to see how this all plays out, or work
in a large development task for a while in a team programming
environment.
My last Windows project involved about 13000 lines of code, 10
engineers in Taiwan, Boston, California, Texas and Japan. The RCS
system worked when the server was up (questionable due to growing pains
of XP at that time), and when all players knew to check out and check in
the files, as well as not rescinding to older revisions without
consultation. This is a truley non-trivial task for any really indepth
project, and windows doesn't handle it at all.
Regards,
Les H
4:51 p.m.
On Tue, 2007-01-02 at 11:08 -0600, Mikkel L. Ellertson wrote:
>
> While I'd expect an editor to normally write back to the original
> file to maintain symlinks, ownership and modes in the case where
> the file is writable, this sounds exactly right and what the
> user would do manually himself in case write access is denied
> and the user has issued the :w! directive. Without the '!' it
> should give a 'file is read-only' error.
>
> Set the sticky bit on the directory if you don't want people
> who don't have write permission on the file to be able to delete
> it. Then they will be forced to save under a different name.
>
Symlinks are maintained as long as the name is the same. Hard links
are another story. I have seen a lot of editors and word processors
that use the write to a new file, and then rename/delete the
original file. It tends to protect your work - the original file is
there in case something goes wrong during the same process. That
way, the worst you lose is the current edits. But as you have
noticed, it does not work out as well when editing shared files.
That's reasonable behavior for a word processor, but not for a
text editor that you are likely to use for system files where
maintaining all attributes is important. There are many situations
where it is impossible for a user with write permission on a file
to recreate its ownership and modes in a different file. And if
you have gone to the trouble of creating hard links it was probably
specifically to ensure that all names reference the same contents.
--
Les Mikesell
lesmikesell(a)gmail.com
7:36 a.m.
Mikkel L. Ellertson wrote:
I have seen a lot of editors and word processors
that use the write to a new file, and then rename/delete the
original file. It tends to protect your work - the original file is
there in case something goes wrong during the same process. That
way, the worst you lose is the current edits.
This behaviour is configurable in Vim: type
:help backup
:help backupcopy
:help writebackup
to see the details.
Use
:set
to see what's currently set. Options can be permanently set in ~/.vimrc.
Hope this helps,
James.
--
E-mail: james@ | I learnt the rules of rugby. There is only one rule.
aprilcottage.co.uk | "Skip it by any means necessary".
| -- "Nix"
6322
days inactive
6330
days old
12 comments
8 participants
participants (8)
-
Cameron Simpson -
Howard Howell -
James Wilkinson -
Joe Smith -
Les Mikesell -
Marcelo Magno T. Sales -
Mikkel -
Tim