Omg

[leigh123linux]

I'm too shocked to rant about this at moment, this has to be the dumbest move yet :eek:



http://lists.fedoraproject.org/pipermail/devel/2010-January/129566.html

[Dies]

I'm too shocked to rant about this at moment, this has to be the dumbest move yet :eek:


http://lists.fedoraproject.org/pipermail/devel/2010-January/129566.html

Why? :confused:

Doesn't sound so bad at all to me. I mean big deal, so you would have to add 'single init=/bin/bash' to the command line instead of just 'single'. So what? Sounds good to me.

Or did I just not understand?

[leigh123linux]

Why? :confused:

Doesn't sound so bad at all to me. I mean big deal, so you would have to add 'single init=/bin/bash' to the command line instead of just 'single'. So what? Sounds good to me.

Or did I just not understand?

If selinux is blocking bash in 'runlevel 1' fix selinux, if they have there way you will require a password for 'runlevel 1' :(


We have an existing bug where if you're in single-user mode, and
SELinux is active, various commands don't print to the console.
The root of this is the single-user shell isn't running in the
right SELinux context, as there's nothing to distinguish this from
the 'normal' shells run during bootup.

By far, the simplest fix is to run something that starts a shell
via a 'normal' login-ish mechanism. Hence, the attached patch
that switches to sulogin for single user mode.

However, this changes behavior that has existed since the dawn
of time in Red Hat/Fedora systems; with this change, single-user
mode would now require the root password. This is both when
booting with 'linux single/linux S', or going to runlevel 1
with 'telinit 1'.

Comments?

Bill
-------------- next part --------------


diff --git a/init/rcS-sulogin.conf b/init/rcS-sulogin.conf
index 4f1f1f1..60360aa 100644
--- a/init/rcS-sulogin.conf
+++ b/init/rcS-sulogin.conf
@@ -1,6 +1,6 @@
# rcS-sulogin - "single-user" runlevel compatibility
#
-# This task runs /bin/bash during "single-user" mode,
+# This task runs /sbin/sulogin during "single-user" mode,
# then continues to the default runlevel.

start on runlevel S
@@ -10,7 +10,7 @@ stop on runlevel [!S]
console owner
script
plymouth --hide-splash || true
- exec /bin/bash
+ exec /sbin/sulogin
end script
post-stop script
if [ "$RUNLEVEL" = "S" ]; then

[Demz]

i really dont think its any great problem, its just a password you'll have to enter

IMO, i never forgot my password in my dayts of using Linux, if you think your gonna forget it, write it down on a Notepad

[leigh123linux]

i really dont think its any great problem, its just a password you'll have to enter

IMO, i never forgot my password in my dayts of using Linux, if you think your gonna forget it, write it down on a Notepad


Well I think it ****ing sucks :( .
Single user mode is common to all distro's why change it :( , they should patch selinux instead to allow it.

[Dies]

If selinux is blocking bash in 'runlevel 1' fix selinux, if they have there way you will require a password for 'runlevel 1' :(

That was my point, if you forget your pass all you need to do is specify 'init=/bin/bash' on the kernel line and you get the old behavior. ;)

[smr54]

Actually Leigh, IIRC, Gentoo (and possibly others) do require the root password in single user mode.

However, as you say, (and as they say in the report) this is the way that RH has done it for years. However, that only matters to them, it seems when they don't want to do something--for example, someone was suggesting changes to anaconda so that it would be possible to see what you were doing when installing on small (less than 10 inch, I guess) netbooks. Someone else mentioned that this is what they've done for years, conveniently not mentioning that for years they had a text install that was fully flexible, rather than the extremely limited version they have now.

Ah well, yet another Fedora decision. <shrug>

[Hlingler]

The proposed change would instantly invalidate countless blogs/posts/tutorials across the internet (and the amassed knowledge of many users) that say how to by-pass a forgotten password (and no doubt assumed when written that the old policy would never change). The erosion and "arbitrary" change of any/all constants is destabilizing and depressing. Change, for changes own sake, or "just because", or as a short-term (and short-sighted) fix to some other issue (caused by something else being busted) is not necessarily good.

I concur with Leigh.

V

[Simian Man]

I agree that this is pretty stupid. It sounds like they are only choosing this fix to avoid fixing a more difficult and deep-seated problem with SELinux.

That said, it really will not affect me. I only have ever entered single-user mode this to reset the root password, and that can still be done with a liveCD + chroot.

[Dies]

...
The proposed change would instantly invalidate countless blogs/posts/tutorials across the internet
...

While that may be true, it already happens in some way, shape or form with just about every release, doesn't it?


;)

[JEO]

Think of it this way, from a security standpoint, if somebody steals your laptop, do you really want to have it easy for them to come here and ask how to reset your root password?

[Dies]

Think of it this way, from a security standpoint, if somebody steals your laptop, do you really want to have it easy for them to come here and ask how to reset your root password?

This won't help in that regard. :(

If someone has physical access to your machine, and you're not using some sort of encryption, they own it. ;)

[SwampKracker]

I have to agree with Leigh. Booting into single user mode is a special case and not meant for normal use. To change anything just for selinux seems rather counter-intuitive. Maybe selinux should automatically be disabled when booting into run level 1. Problem solved.

[kyryder]

If selinux is blocking bash in 'runlevel 1' fix selinux, :(

And yet again the most logical choice (fixing selinux) is disregarded as "they" opt for changing the standards. sigh, seems to be the way society is headed in general or maybe I'm just getting old.

[smr54]

I think both Hlinger and Dies hit the nail on the head--Hlinger with the comment about greatly violating POLA (Principle of Least Astonishment) and Dies with the statement that this occurs with every release.

[CiaW]

If selinux is blocking bash in 'runlevel 1' fix selinux, if they have there way you will require a password for 'runlevel 1' :(

That was basically my reaction when I read it, and I figured NOT fixing selinux would probably cause more problems than it solves -- but I don't use runlevel 1 and I'm still somewhat of a noob so I thought I'd wait to see what others' reactions were. :rolleyes:

[Evil_Bert]

Because they switched to sulogin instead of fixing SELinux in single-user mode, I agree it's not the best solution to this problem.

However, since I'm an advocate of password protecting single-user mode (along with password-protecting grub and BIOS, and investing in a lockable/intrusion detecting case) then I have no complaints that they've done this. In fact, I noticed it had changed in F12 and thought someone might have taken my advice!

It's only the root password needed for single-user mode, and if you can't remember the root password in a Fedora system then much is going to be difficult.

In the greater scheme of things, this seems like a fairly small issue to me. Edit: And isn't Upstart going to completely change this forever, anyway? Runlevels essentially disappear to be replaced with ... well, we don't know yet, but it's supposed to be "dynamic, event-driven service management" or some such.