Bug 167553

Summary:	Good: FutureFeature to be added at next release
Product:	Red Hat Enterprise Linux 3	Reporter:	KW Armstrong <solidbusiness>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED NOTABUG	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	rvokal
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:	2005-09-06 15:23:46 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:

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.