Bug 112948 - unreasonable access restriction with a 'sticky bit' (S_ISVTX)
unreasonable access restriction with a 'sticky bit' (S_ISVTX)
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-06 11:03 EST by Valeriy Ovechkin
Modified: 2007-04-18 13:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:41:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Valeriy Ovechkin 2004-01-06 11:03:21 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
I am seeing an unexpected access restriction while unlinking/
renaming a file in a directory with a 'sticky bit' (S_ISVTX)
set (see the Steps to Reproduce).

The permission settings of the file allow any 'users' group 
member to modify the file 'stickydir/file'. However an attempt 
to unlink the file or replace it with another file is not allowed.

The current behavior of unlink/rename is superfluous because
it does not increase security -- the unlinking/renaming error
can be bypassed by opening the file and rewriting its contents.

Here is one unintended effect of this access restriction. Say,
I wish to modify the file in a "fail-safe" manner. So I would 
prepare an updated version of a file as a tempfile, and then 
make a single system call: rename(tempfile, file). But because
of the current access restriction, rename() will not work!!!
So, the "fail-safe" is impossible with such a file. Instead, I
have to truncate the file, and then write it piece-by-piece.
BUT if interrupted, the file is left in an inconsistent state.

I believe, the unlink/rename/rmdir should succeed if the access
permissions allow modification of the target file/directory.

Thanks!

Version-Release number of selected component (if applicable):
2.4.9-31

How reproducible:
Always

Steps to Reproduce:
#
# Step 1: create a directory with a 'sticky bit' set
#
$ mkdir stickydir
$ chmod 1775 stickydir
$ ls -ld stickydir
rwxrwxr-t   2 user1 users         512 Jan 05 16:10 stickydir

#
# Step 2: create a group-writeable file
#
$ touch stickydir/file
$ chmod 660 stickydir/file
$ ls -l stickydir/file
-rw-rw----   1 user1 users           0 Jan 05 16:11 stickydir/file

#
# Step 3: log in as another user of group 'users'
#
$ su user2
user2's Password:
% groups
users

#
# Step 4: modifying the file succeeds as expected
#
% echo XXX >> stickydir/file
% cat stickydir/file
XXX

#
# Step 5: deleting the file UNEXPECTEDLY FAILS
#
% rm stickydir/file
rm: cannot remove `stickydir/file': Operation not permitted

Additional info:
Comment 1 Bugzilla owner 2004-09-30 11:41:46 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.