From: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>
To: "Lisa R. Nelson" <lisanels@cableone.net>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: File Permissions are incorrect. Security flaw in Linux
Date: Wed, 01 Oct 2003 15:58:00 +0200 [thread overview]
Message-ID: <1065016679.2445.5.camel@teapot.felipe-alfaro.com> (raw)
In-Reply-To: <1065012013.4078.2.camel@lisaserver>
On Wed, 2003-10-01 at 14:40, Lisa R. Nelson wrote:
> [1.] One line summary of the problem:
> A low level user can delete a file owned by root and belonging to group
> root even if the files permissions are 744. This is not in agreement
> with Unix, and is a major security issue.
Don't know which Unix you are referring to, but on Solaris and Linux,
the delete (unlink) and create file operations are subject to directory
permissions. Thus, deleting a file requires write permission on the
directory. The write permission on a file allows to modify its contents
and has nothing to do with being able to delete it.
Thus, what you are seeing is completely normal:
1. mkdir /mydir
2. cd /mydir
3. chmod 777 .
4. touch myfile
5. chmod 444 myfile
Anyone will be able to delete "myfile" since the directory where it
belongs (mydir) has full write privileges for anyone.
I recommend you using the sticky bit on shared directories, like /tmp.
If a directory has the sticky bit enabled, a file can only be deleted by
its owner (and root, of course):
1. mkdir /mydir
2. cd /mydir
3. chmod 1777 .
4. touch myfile
Now, "myfile" can only be deleted by its owner (or root), since the
directory where it belongs is marked with the sticky bit.
HTH
next prev parent reply other threads:[~2003-10-01 13:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-01 12:40 Lisa R. Nelson
2003-10-01 13:08 ` Måns Rullgård
2003-10-01 13:08 ` Mathieu Chouquet-Stringer
2003-10-01 13:23 ` viro
[not found] ` <1065017722.2995.10.camel@localhost.localdomain>
2003-10-01 15:40 ` viro
2003-10-01 19:27 ` DervishD
2003-10-01 13:53 ` Jurjen Oskam
2003-10-01 14:09 ` Richard B. Johnson
2003-10-01 14:22 ` Andreas Schwab
2003-10-01 15:01 ` John Bradford
2003-10-01 13:58 ` Felipe Alfaro Solana [this message]
2003-10-01 14:21 ` DervishD
[not found] ` <1065044031.2158.23.camel@wynken.reefedge.com>
2003-10-01 14:37 ` Lisa R. Nelson
2003-10-01 15:11 ` Bas Mevissen
2003-10-01 15:12 ` Randy.Dunlap
2003-10-01 16:08 ` Richard B. Johnson
2003-10-01 19:21 ` DervishD
2003-10-01 20:30 ` viro
2003-10-01 17:23 ` Brett
2003-10-01 19:24 ` DervishD
2003-10-02 10:32 ` Christian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1065016679.2445.5.camel@teapot.felipe-alfaro.com \
--to=felipe_alfaro@linuxmail.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lisanels@cableone.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®