Bug 125182

Summary: consolehelper breaks with readonly root
Product: [Fedora] Fedora Reporter: Alexander Larsson <alexl>
Component: usermodeAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 2   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-26 09:45:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 124120    
Attachments:
Description Flags
Fix for the problem
none
new version of the patch none

Description Alexander Larsson 2004-06-03 14:04:17 UTC
If the root filesystem is readonly, consolehelper fails.
What happens is that userhelper.c:wrap() does:

        s = svNewFile(apps_filename);

        /* If the file is world-writable, or isn't a regular file, or
couldn't
         * be opened, just exit.  We don't want to alert an attacker
that the
         * service name is invalid. */
        if ((s == NULL) ||
            (fstat(s->fd, &sbuf) == -1) ||
            !S_ISREG(sbuf.st_mode) ||
            (sbuf.st_mode & S_IWOTH)) {

However, if the file is readonly (or on a readonly filesystem as in
this case) then svNewFile closes the fd. The attached patch fixes this
by not closing the fd in this case (as that seems to be an
optimization only).

Comment 1 Alexander Larsson 2004-06-03 14:05:24 UTC
Created attachment 100830 [details]
Fix for the problem

Comment 2 Dave Malcolm 2004-08-16 19:40:27 UTC
Nalin: please can you comment on Alex's patch?

Comment 3 Nalin Dahyabhai 2004-08-20 22:43:15 UTC
The patch looks good from here, both in rationale and implementation.  
I'd like you to modify the patch so that it stores the mode with which
the file was opened in the returned structure.  Previously, a calling
application could check (fd != -1) and be sure that the file could be
modified, but the patch removes that, so you end up depending on an
ftruncate() failing when the application attempts to write to the file.
(If we ever actually get this code factored out into a single common
implementation, we'll need something to address that.)

Comment 4 Alexander Larsson 2004-08-23 08:13:32 UTC
Created attachment 102978 [details]
new version of the patch

New patch attached that keeps track of whether you can write to fd or not.

Comment 5 Nalin Dahyabhai 2004-08-24 15:03:56 UTC
An is-writable field works just as well.  Okay to commit.

Comment 6 Alexander Larsson 2004-08-26 09:45:41 UTC
Commited and built as usermode-1.71-1.