Bug 125182 - consolehelper breaks with readonly root
consolehelper breaks with readonly root
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: usermode (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
David Lawrence
:
Depends On:
Blocks: ReadOnlyFS
  Show dependency treegraph
 
Reported: 2004-06-03 10:04 EDT by Alexander Larsson
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-26 05:45:41 EDT
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 10:05 EDT, Alexander Larsson
no flags Details | Diff
new version of the patch (1.91 KB, patch)
2004-08-23 04:13 EDT, Alexander Larsson
no flags Details | Diff

  None (edit)
Description Alexander Larsson 2004-06-03 10:04:17 EDT
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 10:05:24 EDT
Created attachment 100830 [details]
Fix for the problem
Comment 2 Dave Malcolm 2004-08-16 15:40:27 EDT
Nalin: please can you comment on Alex's patch?
Comment 3 Nalin Dahyabhai 2004-08-20 18:43:15 EDT
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 04:13:32 EDT
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 11:03:56 EDT
An is-writable field works just as well.  Okay to commit.
Comment 6 Alexander Larsson 2004-08-26 05:45:41 EDT
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.