Bug 112943 - Bug submission hangs
Bug submission hangs
Status: CLOSED WORKSFORME
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
2.18
All Linux
medium Severity high (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
David Lawrence
https://bugzilla.redhat.com/bugzilla/...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-06 10:37 EST by Valeriy Ovechkin
Modified: 2013-06-23 22:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-31 23:51:20 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 10:37:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
I filled in a New kernel bug report starting at
https://bugzilla.redhat.com/bugzilla/easy_enter_bug.cgi

(using the wizard, I believe)

Then, at the last page, after I clicked on the 
"Open Bugzilla Entry Form", a new browser window
(IE6) opened, and stayed blank for many many hours,
trying to open the page.

I think I filed a similar report over a year ago...

Version-Release number of selected component (if applicable):
Bugzilla Version 2.17.1

How reproducible:
Sometimes

Steps to Reproduce:
1. File a kernel bug
2. Submit a bug
3. See the hanging window
    

Actual Results:  the bug submission page never comes back

Expected Results:  able to submit a bug

Additional info:
Comment 1 Valeriy Ovechkin 2004-01-06 10:51:16 EST
I believe the hanging occurs when the Description + Steps to 
Reproduce fields are filled in with specific info. Follow these
steps to reproduce:

1. start on page 
[https://bugzilla.redhat.com/bugzilla/easy_enter_bug.cgi]
2. scroll down and click on the [Step 3. Choosing Your Product] button
3. select [Red Hat Linux]
4. click on the [Step 4. Choosing Component] button
5. select [kernel] Component
6. select [9] Version
7. select [All] Platform
8. click on the [Step 6. Additional Information] button
9. type [Trying to reproduce Bug 112943] in Summary
10. type [kernel-2.4.18-14] in version-release
11. copy/paste into Description:

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!

12. select [Every time.] in Reproducibility
13. copy/paste into 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

14. click on the [Open Bugzilla Entry Form] button
Comment 2 Robin Green 2004-01-18 16:26:10 EST
I am also seeing this.
Comment 3 David Lawrence 2006-04-08 13:55:13 EDT
Red Hat's current Bugzilla version is 2.18. I am moving all older open bugs to
this version. Any bugs against the older versions will need to be verified that
they are still bugs. This will help me also to sort them better.
Comment 4 David Lawrence 2007-10-31 23:51:20 EDT
Enhancements have been made lately to improve the guided bug entry form. Please
reopen this bug if the problem still occurs.

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