Xref: utzoo gnu.emacs.help:1801 comp.emacs:10576 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!sgihub!dragon!dragon!jackr From: jackr@dblues.wpd.sgi.com (John "Jack" Repenning) Newsgroups: gnu.emacs.help,comp.emacs Subject: Re: Saving a file in emacs without the right permission bits Message-ID: Date: 19 Apr 91 15:22:05 GMT References: <1991Apr18.220342.25107@sj.ate.slb.com> <1991Apr19.052504.2074@Think.COM> Sender: news@dragon.wpd.sgi.com (CNews Account) Distribution: usa Organization: Silicon Graphics, Inc. Lines: 41 In-Reply-To: ramabads@cs.rpi.edu's message of 19 Apr 91 16:57:58 GMT In article ramabads@cs.rpi.edu (Shiva ) writes: Excuse this dumb question, but should'nt the owner be the only person who is allowed to rename files ??? Especially if the permissions are 644 as Kanan claims ??? Renaming is allowed for anyone with write permission on the directory. That's a UN*X rule, out of Emacs' hands. (Maybe you meant, "this is a dumb rule," in which case your philosophy is supportable, but purely academic in the face of the well-established precedent.) Removing a file is also controlled by directory permissions, not file permissions (although rm(1) takes the trouble to ask if you really meant that, if file permissions are set against you - and, if you don't specify "-f"). Putting different data into a file depends upon write permissions on the file, which makes sense. Changing permissions on a file also depends upon write permissions on the file, rather than on the directory as you might suppose (if you reason vaguely that permissions are some kind of meta-data, perhaps). Of course, it's necessary that write permissions on the file control the right to change permissions, else the write permissions on the file are a mere mockery. But since renaming is controlled in blythe disregard for the permissions on the file itself, there's certainly a bit of mockery here: without write permission on the file, you may (a) rename a file to something else, (b) copy its content to a new file of the same name, (c) change the contents of the new file, and finally (d) remove the old file. Sure *looks* like you changed the contents of the file, doesn't it? (Unless you use the "ls -i" trick to notice the changed inode number - which is hardly a comfort to anyone who wanted the file contents not to change!) Jack Repenning 9U-530 jackr@wpd.sgi.com Silicon Graphics, Inc. Off:(415) 335-7477 Systems Software Technology Center Fax:(415) 969-2314