Bug 125182 - consolehelper breaks with readonly root
Summary: consolehelper breaks with readonly root
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: usermode   
(Show other bugs)
Version: 2
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: ReadOnlyFS
TreeView+ depends on / blocked
 
Reported: 2004-06-03 14:04 UTC by Alexander Larsson
Modified: 2007-11-30 22:10 UTC (History)
0 users

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: ---


Attachments (Terms of Use)
Fix for the problem (1.11 KB, patch)
2004-06-03 14:05 UTC, Alexander Larsson
no flags Details | Diff
new version of the patch (1.91 KB, patch)
2004-08-23 08:13 UTC, Alexander Larsson
no flags Details | Diff

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.


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