Return to BSD News archive
Xref: sserve comp.os.386bsd.bugs:3016 comp.os.386bsd.questions:16745 comp.security.unix:10753
Newsgroups: comp.os.386bsd.bugs,comp.os.386bsd.questions,comp.security.unix
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!gmi!zombie.ncsc.mil!news.mathworks.com!uunet!monoli!csoft!bag
From: bag@monolit.kiev.ua (Andrey Blochintsev)
Subject: Symbolic links in dirs with 't' bit ???
Organization: CS/MONOLIT Network Centre
Date: Wed, 22 Feb 1995 16:27:26 GMT
Message-ID: <D4Etpr.18q@monolit.kiev.ua>
X-Newsreader: TIN [version 1.2 PL2]
Lines: 45
The FreeBSD 2.0 man for symlink(7) say:
| Unlike other filesystem objects, symbolic links do not have an owner,
^^^^^
| group, permissions, access and modification times, etc. The only at-
| tributes returned from an lstat(2) that refer to the symbolic link itself
| are the file type (S_IFLNK), size, blocks, and link count (always 1).
| The other attributes are filled in from the directory that contains the
| link. For portability reasons, you should be aware that other implemen-
| tations (including historic implementations of 4BSD), implement symbolic
| links such that they have the same attributes as any other file.
In many Unix'es directories for temporary files (/tmp, /var/tmp)
have permissions like this:
drwxrwxrwt 12 root wheel 512 Feb 22 17:16 /tmp
^ Sticky bit set. This mean that user can delete
(or rename) file from this directory only if he have write access to
this directory and he is a owner of this file (last condition changed
to 'have write access to file' in some unix'es).
FreeBSD-2.0 realization of symlink's allow symlink creation
at any writable by user directory but don't allow always remove it.
For example:
bag@im /tmp > make file
bag@im /tmp > ln -s file symlink
bag@im /tmp > ls -laFgd /tmp
-rw-r--r-- 1 bag wheel 11604 Feb 22 17:15 /tmp/file
lrwxrwxrwt 1 root wheel 4 Feb 22 17:16 /tmp/symlink@ -> file
drwxrwxrwt 12 root wheel 512 Feb 22 17:16 /tmp/
bag@im /tmp > rm file symlink
rm: symlink: operation not permitted
This problem can be solved if I remove 't' bit from all directories (or
hack kernel to disable 't' bit), but this also decrease a security of system.
So, does symlink owner and group must be reinserted into system ?
Any suggestion is appreciated
Andrey