Bug 591065 - hal-lock closes standard file descriptors [NEEDINFO]
hal-lock closes standard file descriptors
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: hal (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Richard Hughes
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-11 07:15 EDT by Ales Kozumplik
Modified: 2017-12-06 07:31 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-06 07:31:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rhughes: needinfo? (davidz)


Attachments (Terms of Use)

  None (edit)
Description Ales Kozumplik 2010-05-11 07:15:40 EDT
Description of problem:
Running 
$ /usr/bin/hal-lock --interface org.freedesktop.Hal.Device.Storage --exclusive --run bash

terminates immediately instead of starting the bash interactively and only exiting after the uses enters ctrl-d for the end of file.

Looking at the code this is because the program specified at --run is spawned using g_spawn_command_line_sync() and this method doesn't allow specifying flags, G_SPAWN_LEAVE_DESCRIPTORS_OPEN in particular, see:

http://library.gnome.org/devel/glib/stable/glib-Spawning-Processes.html

This is actually a serious setback for the rhel6 livecd development because this prevents us from running PDB from anaconda.
Comment 1 Richard Hughes 2010-05-11 07:30:26 EDT
(In reply to comment #0)
>terminates immediately instead of starting the bash interactively

I'm not sure if this is intended or not. I guess there are no security/logic implications to using G_SPAWN_LEAVE_DESCRIPTORS_OPEN. It would certainly be a pretty trivial patch to use this. David, can I have your comments please, as I think you are the original author.

> This is actually a serious setback for the rhel6 livecd development because
> this prevents us from running PDB from anaconda.    

Isn't PDB the debugging environment? Doesn't this work in Fedora? Can't you comment out the hal-lock statement to continue development?

Richard
Comment 3 Ales Kozumplik 2010-05-11 09:04:35 EDT
Also, I talked to David yesterday about the same problem with "devkit-disks --inhibit" and he suggested a workaround where I call the devkit-disks' "Inhibit" through dbus. Is there something similar available with hal-lock?
Comment 4 RHEL Product and Program Management 2010-05-11 09:12:04 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 5 Richard Hughes 2010-05-11 13:30:03 EDT
(In reply to comment #3)
> Also, I talked to David yesterday about the same problem with "devkit-disks
> --inhibit" and he suggested a workaround where I call the devkit-disks'
> "Inhibit" through dbus. Is there something similar available with hal-lock?    

Sure, it's a fair bit of code tho. On a related not, shouldn't you guys be using udisks for RHEL6 too?
Comment 6 Ales Kozumplik 2010-05-12 02:16:29 EDT
Hi Richard,

Isn't udisks basically the same thing as devkit-disks, just a different name?

Anyway --- I can just exclusively lock org.freedesktop.Hal.Device.Storage using dbus? Is there a reference? And why do you say it's a lot of code: isn't that just about creating the system session, obtaining the interface and then calling something like "Lock" ?
Comment 7 RHEL Product and Program Management 2010-07-15 10:23:34 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 8 RHEL Product and Program Management 2011-04-03 21:51:11 EDT
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 11 Suzanne Yeghiayan 2012-02-14 17:59:21 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 13 Jan Kurik 2017-12-06 07:31:31 EST
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/

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