[Top] [All Lists]

Re: TAKE - change symlink perms to 777

To: linux-xfs@xxxxxxxxxxx
Subject: Re: TAKE - change symlink perms to 777
From: Ethan Benson <erbenson@xxxxxxxxxx>
Date: Sun, 15 Sep 2002 04:12:24 -0800
In-reply-to: <20020915110030.GH17696@xxxxxxxxxxxx>
Mail-copies-to: nobody
Mail-followup-to: linux-xfs@xxxxxxxxxxx
References: <200209102023.g8AKNdB29305@xxxxxxxxxxxxxxxxxxxxxx> <20020910212614.GA10273@xxxxxxxxxxxxx> <20020911071824.GG714@xxxxxxxxxxxxxxx> <20020911122332.GD17696@xxxxxxxxxxxx> <20020911193759.GJ714@xxxxxxxxxxxxxxx> <20020915110030.GH17696@xxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.28i
On Sun, Sep 15, 2002 at 01:00:30PM +0200, Wessel Dankers wrote:
> On 2002-09-11 11:37:59-0800, Ethan Benson wrote:
> > > They are not. Consider a sticky directory.
> > what are you talking about? they are still irrelevant.
> Usually, sticky directories check unlink() authorisation by looking at the
> access bits of the file itself.

you are wrong, sticky directories check the ownership of the file and
only allow unlink() if the file owner matches the uid of the user
attempting unlink(), or if the user owns the sticky directory, or the
user is root.  the file's permissions have absolutly nothing to do
with it.  

and if they did forcing symlinks to mode 777 would be a security hole
since it would allow any user to always delete them in sticky dirs.

> It seems that Linux currently always returns EPERM when you try to delete a
> symlink that is not owned by you if it's in a sticky directory. It wasn't
> like that the last time I tested it, so I was basing my statement on
> outdated assumptions. Sorry.

i have never heard of symlinks being treated special in this manner,
they are just files like anything else.

> You are right, symlink permissions are completly irrelevant. Even
> readlink() isn't thwarted by them.

from chmod(1)

chmod never changes the permissions of symbolic links; the chmod
system call cannot change their permissions.  This is not a problem
since the permissions of symbolic links are never used.

Ethan Benson

Attachment: pgpjS8CF5iNzt.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>