Bug 167553 - Good: FutureFeature to be added at next release
Summary: Good: FutureFeature to be added at next release
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-09-05 10:28 UTC by KW Armstrong
Modified: 2014-03-17 02:55 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-06 15:23:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description KW Armstrong 2005-09-05 10:28:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922

Description of problem:
Of course modifying boot scripts is by no means that difficult. However, it is a matter of utmost importance as it will only enhance security being implemented as a default solution. 

Prompt the user before loading of devfs, if the user chooses to run it -  or during the call in the /etc/rc*scripts for /sbin/init, how the user wants to log in( i.e. default run-level for the preferred login). It is also a good idea to add to the etc/rc.d/init.d scripts the option of running processes as user or root.

I believe TRUE root should not be running X. There are far to many processes a hacker may access if someone chooses to run X as root though it is foolish. 

The xfs filesystem daemon should only be invoked in a chroot directory for the same reason. I don't think it would hurt if first-boot carried the user into X to implement the desired situation. In this manner, a FutureFeature-Dialog could interact with the user to produce the end result.

Version-Release number of selected component (if applicable):
kernel-2.4.21-4.EL

How reproducible:
Always

Steps to Reproduce:
1.call of /sbin/init
2.check run-level
3.start-stop services/daemons
  

Additional info:

Comment 1 Bill Nottingham 2005-09-06 15:23:46 UTC
- there is no loading of devfs
- there is no 'xfs filesystem daemon'
- there already is the --user option to daemon in /etc/init.d/functions for
scripts to run as an alternate user
- you can pass the default level on the commandline


Comment 2 KW Armstrong 2005-09-11 06:47:09 UTC
- by loading devfs I am speaking of implimenting devfs in the scripts after the
daemon is compiled.

- as far as no xfs daemon there ought to be... please hear me.

GNU already has the ability to wrap sshd around tcpd and tcpd around what ever
else: if an xfs daemon is created, one can tunnel xfs so as to not take up the
whole of the screen. You can bring up different terminal windows this way when
the wrapping is as so... sshd -> tcpd -> xfsd. This scenario would give one the
ability to bring up the different terminal windows in different colors to
indicate different warning levels of state change or intrusion. 

This way you can diagnose all of your processes in real-time at every run-level
at the same-time. 


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