[aklug] Re: Strange hard linking

From: Shane Spencer <shane@bogomip.com>
Date: Sat Nov 27 2010 - 11:14:34 AKST

On Sat, Nov 27, 2010 at 9:22 AM, Shane Spencer <shane@bogomip.com> wrote:
> On Sat, Nov 27, 2010 at 2:41 AM, =A0<bryanm@acsalaska.net> wrote:
>> On Fri, November 26, 2010 5:45 pm, Shane R. Spencer wrote:
>>> On 11/26/2010 02:24 PM, Christopher Howard wrote:
>>>> So, I was messing around the other day, and found this rather wierd be=
havior
>>>> in Linux:
>> <snip>
>>>> So, in summary, as a non-root user, I have the ability to "create"
>>>> (preserve?) files that I do not own and that I cannot delete.
>>>>
>>>
>>> What filesystem are you using? What distro?
>>>
>>> Shouldn't be possible if your operating system is at all secure (doesn'=
t run
>>> ln as setuid
>>> root). =A0You cannot modify (including create) files owned by root even=
 if it's
>>> the same
>>> inode as another file. =A0In order not to sound like a dork I attempted=
 the
>>> following on
>>> XFS/JFS2/GFS2/NFS+EXT4/EXT4
>>>
>>> =A0 =A0spencersr@banzai:/tmp$ sudo touch woman
>>> =A0 =A0spencersr@banzai:/tmp$ ln woman man
>>> =A0 =A0ln: creating hard link `man' =3D> `woman': Operation not permitt=
ed
>>>
>>> Here.. running ln as setuid root gets things rocking :)
>>>
>>> =A0 =A0spencersr@banzai:/tmp$ sudo chmod u+s /bin/ln
>>> =A0 =A0spencersr@banzai:/tmp$ ln woman man
>>> =A0 =A0spencersr@banzai:/tmp$ ls -lai man woman
>>> =A0 =A034857277 -rw-r--r-- 2 root root 0 2010-11-26 17:36 man
>>> =A0 =A034857277 -rw-r--r-- 2 root root 0 2010-11-26 17:36 woman
>>
>> This is really interesting. =A0Let me add my own data. =A0On my
>> Slackware 11 box, I'm able to create root-owned links, just
>> as Christopher did, on JFS and EXT3 filesystems. =A0A minix
>> filesystem will *not* let me do it.
>>
>> The directory you're in makes a difference, though. =A0I'm able
>> to hardlink *and* remove root-owned files in a directory owned
>> by my regular user.
>>
>> Shane, do you have any older filesystems you could try on the
>> same system? =A0That could help narrow down whether it's a
>> filesystem issue or an OS (Linux VFS?) issue.
>>
>
> Do me a favor and try again. =A0This time make sure you aren't running
> "sudo mount ...". =A0Doing so without erasing your environment will set
> the mount point to be owned by the user running sudo... This makes it
> easy for some filesystems grant permissions to nodes created in the
> root node as the mount point owner. =A0I believe this is a bug in mount.

BTW.. check out the following in 'man chmod'

RESTRICTED DELETION FLAG OR STICKY BIT
The restricted deletion flag or sticky bit is a single bit, whose
interpretation depends on the file type. For directories, it prevents
unprivileged users from removing or renaming a file in the directory
unless they own the file or the directory; this is called the
restricted deletion flag for the directory, and is commonly found on
world-writable directories like /tmp. For regular files on some
older systems, the bit saves the program's text image on the swap
device so it will load more quickly when run; this is called the
sticky bit.

In most filesystems.. if you own the directory that other peoples
files (OPF) reside directly in.. feel free to delete them. You can
ultimately secure your system by not storing things this way :) or
using the sticky bit. If you want to manage hosting for lots of
accounts and want to have a .bashrc owned by root in all directorys..
better use the sticky bit.

- Shane
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sat Nov 27 11:14:41 2010

This archive was generated by hypermail 2.1.8 : Sat Nov 27 2010 - 11:14:42 AKST