Standards, the kernel, and Postfix [LWN.net]

Standards, the kernel, and Postfix

Posted Aug 21, 2008 8:58 UTC (Thu) by adegert (subscriber, #5503)
In reply to: Standards, the kernel, and Postfix by magnus
Parent article: Standards, the kernel, and Postfix

its even more odd if you create the link in a directory which has the sticky bit set:

ln /etc/shadow /tmp/myfile

you can create that link, but you can't delete it afterwards (only root can do that)

(Log in to post comments)

Standards, the kernel, and Postfix

Posted Aug 21, 2008 15:43 UTC (Thu) by foom (subscriber, #14868) [Link]

> ln /etc/shadow /tmp/myfile
> you can create that link, but you can't delete it afterwards (only root can do that)

Wow, that's insane!

I'd never thought about this issue of hardlinks...but it kinda seems bad that
you can create a file  owned by another user.

Standards, the kernel, and Postfix

Posted Aug 22, 2008 23:44 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

it kinda seems bad that you can create a file owned by another user.

You can't create a file owned by another user. But you can create a directory entry that points to a file owned by another user.

It all seems strange compared to what you can do with symbolic links, but if you think about the early systems that didn't have symbolic links, you can see how useful it is.

I think what would have given me pause in the pre-symbolic-link days was not that I could keep a pointer to your file in my directory, but that I could prevent you from deleting that file. So while I can't create a file owned by you, I can force you to keep owning one that only I am using. If the system does accounting, you have to pay for the space.

Altogether, I think Unix should have either made files and their names completely separate, like VMS, or completely merged, like NTFS. The intermediate thing has too many surprises.

Standards, the kernel, and Postfix

Posted Aug 30, 2008 14:37 UTC (Sat) by abpsoft (guest, #53672) [Link]

Hi,

> its even more odd if you create the link in a directory which has the sticky bit set:
> ln /etc/shadow /tmp/myfile
> you can create that link, but you can't delete it afterwards (only root can do that)

Hmpf.

Actually I consider this to be an implementation bug of the directory sticky bit semantics. It should prevent from happening *any* changes to the directory involving names to inodes the subject process doesn't own. Most users just think about unlink(2)ing files, but it also prevents rename(2) from succeeding. Not blocking directory entry creation through link(2) in the first place thus should be considered incomplete implementation, or is there explicit standard language stating otherwise? I haven't read much beyond XPG4 ;)

Andre.