touch modifies read-only files

[Dan Bar Dov]

If the file is owned by the user, touch will modify its last-mod-time.
This is contrary to my understanding that a read only file cannot be
modified (unless I insist as in rm -f)

Is this standard on all Unixes?


Dan

[nate]

Post by Dan Bar Dov
If the file is owned by the user, touch will modify its last-mod-time.
This is contrary to my understanding that a read only file cannot be
modified (unless I insist as in rm -f)
Is this standard on all Unixes?

if the file is owned by the same user that is 'touching' it, that
user can override any permissions.

try, e.g. vi a read-only file by the user, then try to save it, it
will say it's read only, then save it with :w! it will happily override
it.

I think it's up to the particular program if it wants to deny access
to the file based on permissions, I think most tend to ignore readonly
permissions, becuase if the user really wants to write to it, they have
full rights to change the permissions of the file and then write to
it.

of course if the file is not owned by the owner, then the system
should block access to it, and the app won't be able to override.

I am not sure if this is standard, but you shouldn't rely on this
sort of test with touch. I don't feel like powering up my solaris
machines but my FreeBSD 4.7 system shows the same behavior. My
RS/6000 and SGI Indy aren't plugged in either.

nate

[Cameron Simpson]

On 00:45 30 Jan 2003, nate <***@aphroland.org> wrote:
| Dan Bar Dov said:
| > If the file is owned by the user, touch will modify its last-mod-time.
| > This is contrary to my understanding that a read only file cannot be
| > modified (unless I insist as in rm -f)
| > Is this standard on all Unixes?
|
| if the file is owned by the same user that is 'touching' it, that
| user can override any permissions.

Um, NO. The user can _change_ the permissions, then do stuff, then
change them back, because they own it. But if the user permissions say
"no write access" then until they change them the user can't write to
the file. That's what the user set of permssions is for!

However, touch uses the utime() call, not actual file data writing,
and this date change is permitted. You still can't change the data
unless you change the permissions first.

| try, e.g. vi a read-only file by the user, then try to save it, it
| will say it's read only, then save it with :w! it will happily override
| it.

Not so.

Unless your vi (vim probably) is doing evil things like unlinking the
old file and making a new one, the above does not work.

| I think it's up to the particular program if it wants to deny access
| to the file based on permissions, I think most tend to ignore readonly
| permissions, becuase if the user really wants to write to it, they have
| full rights to change the permissions of the file and then write to
| it.

You're living in some weird fantasy land my friend. Programs must not
second guess policy, and permissions are policy. Fortunately the OS
prevents such stupidity in programs unless the program is truly offensive
and mods permissions without asking.

Cheers,
--
Cameron Simpson, DoD#743 ***@zip.com.au http://www.zip.com.au/~cs/

The question seems to be of such a character that if I should come to
life after my death and some mathematician were to tell me that it had
been definitely settled, I think I would immediately drop dead again.
- Vandiver

[C***@csiro.au]

Post by Dan Bar Dov
If the file is owned by the user, touch will modify its
last-mod-time. This is contrary to my understanding that a read only
file cannot be modified (unless I insist as in rm -f)
Is this standard on all Unixes?

[snip]...
I am not sure if this is standard, but you shouldn't rely on this
sort of test with touch. I don't feel like powering up my solaris
machines but my FreeBSD 4.7 system shows the same behavior. My
RS/6000 and SGI Indy aren't plugged in either.
nate

Same on Solaris.

If you think about it, the times are in the inode, not the file.
Blocking write permissions to a file cannot also block write permission
to the inode, because that is where the permissions are stored - but
you don't have general access to the inodes anyway.

Whether the file is actually writable or not,
touch is still just lying about it being modified. It does
not actually modify it.

I then started trying to remember how touch works -
the system call it uses is utime(2), so you can read the man page
on the defined permissions for modification. I tried on the Solaris
man page but it left me too confused to repeat here.
I think they meant it is ok if
you are effectively root, or the owner, or have write permission.
Different permissions might apply if you are trying
to set another time in the past or the future.
I presume there's a Posix standard for it. Somewhere.

Cameron.

[Rigler, S C (Steve)]

I guess I must have an evil vi on all of my machines, because I've been
doing this for some time (using ":w!" to override read-only permission
when I own the file).

-Steve

-----Original Message-----
From: Cameron Simpson [mailto:***@zip.com.au]
Sent: Thursday, January 30, 2003 9:46 PM
To: redhat-***@redhat.com
Subject: Re: touch modifies read-only files


| try, e.g. vi a read-only file by the user, then try to save it, it
| will say it's read only, then save it with :w! it will happily override
| it.

Not so.

Unless your vi (vim probably) is doing evil things like unlinking the
old file and making a new one, the above does not work.

[Todd A. Jacobs]

Post by Rigler, S C (Steve)
I guess I must have an evil vi on all of my machines, because I've been
doing this for some time (using ":w!" to override read-only permission
when I own the file).

The problem is that if you have write permissions on the directory, you
can add and delete directory entries regardless of the permissions on the
file itself.

Some editors (vi is a good example) don't edit the actual file; they edit
a temporary copy the way all good multi-user utilities should. If you do a
":w!" and you have sufficient privelege for the directory, it can unlink
the file and move the temporary data to a new file with the old name and
permissions.

It only *looks* like it's over-writing the old file. It isn't. But the end
result is the same.

[Cameron Simpson]

On 22:59 30 Jan 2003, Todd A. Jacobs <***@codegnome.org> wrote:
| On Thu, 30 Jan 2003, Rigler, S C (Steve) wrote:
| > I guess I must have an evil vi on all of my machines, because I've been
| > doing this for some time (using ":w!" to override read-only permission
| > when I own the file).
|
| The problem is that if you have write permissions on the directory, you
| can add and delete directory entries regardless of the permissions on the
| file itself.
|
| Some editors (vi is a good example) don't edit the actual file; they edit
| a temporary copy the way all good multi-user utilities should. If you do a
| ":w!" and you have sufficient privelege for the directory, it can unlink
| the file and move the temporary data to a new file with the old name and
| permissions.

Vim will do this (there's some setting for it). Most vis don't. They
all edit a copy, but generally overwrite the original.

| It only *looks* like it's over-writing the old file. It isn't. But the end
| result is the same.

No, not quite. Consider:

echo hi >foo # make file
chmod 444 foo # remove write permission
ln foo bah # link to second name
umask 2 # just to ensure
vim foo # and go :w!

If your hypothesis were correct there would be two distinct files now,
the "foo" one with a mode 664. (Which is a core reason I loathe apps
which do the unlink/new-file thing.) A quick experiment reveals that vim
leaves them linked with the perms ok. So it must in fact be tweaking the
permissions to add write, rewriting, and putting the permissions back.
Which is sort of ok in my book.

Still, I use nvi mostly, and expect to have to tweak perms if I lock
myself out - I will have done it for a reason, after all.
--
Cameron Simpson, DoD#743 ***@zip.com.au http://www.zip.com.au/~cs/

A host is a host from coast to coast
& no one will talk to a host that's close
Unless the host (that isn't close)
is busy, hung or dead
- David Lesher, ***@skybridge.scl.cwru.edu