5:32 p.m.
Hi,
I discovered that xscreensaver and lock screen does not work in gnome if
the current user is "root".
Is this a bug or a "feature" ?
And another question, is there an options to change the unlock prompt from
xscreensaver ? The default one is UGLY, and does not fit in Gnome desktop.
Thanks,
5:37 p.m.
Paul Ionescu wrote:
Hi,
I discovered that xscreensaver and lock screen does not work in gnome if
the current user is "root".
Is this a bug or a "feature" ?
And another question, is there an options to change the unlock prompt from
xscreensaver ? The default one is UGLY, and does not fit in Gnome desktop.
This has NEVER worked for root. It has something to do with
xscreensaver not being very secure. In any case you shouldn't be
logging in as root anyway. You should use su or sudo when you need root
functions.
Warren Togami
wtogami(a)redhat.com
5:44 p.m.
On Sun, 17 Oct 2004 12:37:57 -1000, Warren Togami wrote:
This has NEVER worked for root. It has something to do with
xscreensaver
not being very secure. In any case you shouldn't be logging in as root
anyway. You should use su or sudo when you need root functions.
Well, I know that, but it works fine in KDE.
And if somebody insist to log in as root, it is even more dangerous that
he cannot lock the screen.
9:47 a.m.
I can see why is it unsecure to login as root, but why deny them a "lock
screen"? What more can be done than
- Killing the Xserver via the three-finger-salute
- Killing xscreenserver via a root account... Oh... You need to be root
to do that, right?
GUI root can be usefull sometimes. Such as when your auth setup has
totally screwed up, and you need to run
"system-config-authentification".
As far as i can see, the only effective way to prevent people from login
in to root, is to remove all usefull gui setup tools...
man, 18.10.2004 kl. 00.44 skrev Paul Ionescu:
On Sun, 17 Oct 2004 12:37:57 -1000, Warren Togami wrote:
> This has NEVER worked for root. It has something to do with xscreensaver
> not being very secure. In any case you shouldn't be logging in as root
> anyway. You should use su or sudo when you need root functions.
Well, I know that, but it works fine in KDE.
And if somebody insist to log in as root, it is even more dangerous that
he cannot lock the screen.
6:16 p.m.
> Well, I know that, but it works fine in KDE.
> And if somebody insist to log in as root, it is even more dangerous that
> he cannot lock the screen.
If logging in as root to a graphical session truly
is a badthing(tm)
could one not argue that gnome/kde/yourfaviorite gui sessions should
be disabled for root by default? GUI admin tools are still available
from the application menu(s) in user sessions, along with all of the
cli goodness from a terminal + su -/sudo whatever.
(fully expecting to get my butt kicked for this suggestion)
--
Bests,
Jon
7:27 p.m.
On Mon, 2004-10-18 at 16:16 -0700, Jon Savage wrote:
> > Well, I know that, but it works fine in KDE.
> > And if somebody insist to log in as root, it is even more dangerous that
> > he cannot lock the screen.
If logging in as root to a graphical session truly is a badthing(tm)
could one not argue that gnome/kde/yourfaviorite gui sessions should
be disabled for root by default? GUI admin tools are still available
from the application menu(s) in user sessions, along with all of the
cli goodness from a terminal + su -/sudo whatever.
(fully expecting to get my butt kicked for this suggestion)
I agree with you, fwiw. Any reason to need to log in as root is a bug.
Havoc
7:28 p.m.
Havoc Pennington wrote:
On Mon, 2004-10-18 at 16:16 -0700, Jon Savage wrote:
>>>Well, I know that, but it works fine in KDE.
>>>And if somebody insist to log in as root, it is even more dangerous that
>>>he cannot lock the screen.
>
>If logging in as root to a graphical session truly is a badthing(tm)
>could one not argue that gnome/kde/yourfaviorite gui sessions should
>be disabled for root by default? GUI admin tools are still available
>from the application menu(s) in user sessions, along with all of the
>cli goodness from a terminal + su -/sudo whatever.
>
>(fully expecting to get my butt kicked for this suggestion)
>
I agree with you, fwiw. Any reason to need to log in as root is a bug.
Havoc
Maybe SuSE or Mandrake's scary red background if you login as root is a
good idea. Should we implement that for RHEL4?
Warren Togami
wtogami(a)redhat.com
7:32 p.m.
Maybe SuSE or Mandrake's scary red background if you login as
root is a
good idea. Should we implement that for RHEL4?
Disable root graphical logins.
Period.
make it so gdm or kdm or xdm just exit.
hell, you could make the xinitrc script handle it:
if your uid is 0 then you throw up a hate-filled messaged and exit.
EOD.
If you can't flip to a console and take care of the problem there as
root, then you REALLY don't need to be logged into a graphical client to
do it.
-sv
7:44 p.m.
Disable root graphical logins.
Period.
make it so gdm or kdm or xdm just exit.
hell, you could make the xinitrc script handle it:
if your uid is 0 then you throw up a hate-filled messaged and exit.
EOD.
If you can't flip to a console and take care of the problem there as
root, then you REALLY don't need to be logged into a graphical client to
do it.
Bite me !
I want to run some of my boxes as root with X, not to mention the
problems this would cause trying to work with some cluster setups and
embedded boxes. I have X code then even requires to run UID 0.
Users should have the power to choose, even if you personally think its
a poor choice.
If you have such a security fetish then go play with firewall rules in
the corner and leave us users to decide how to operate our machines !
Jon
8:12 p.m.
On Tue, 19 Oct 2004 01:44:26 +0100, Jonathan Andrews
<jon(a)jonshouse.co.uk> wrote:
Bite me !
Tell me where i get in line.
Users should have the power to choose, even if you personally think
its
a poor choice.
Choose what? Choose to use less secure defaults? Choose to recompile
software using less secure settings? Choose to write their own
software?
Here let me reparse what seth said with my "by default" clause
post-processor and see if you can stomach my version:
Disable root graphical logins..... by default
Period.
make it so gdm or kdm or xdm just exit... by default
hell, you could make the xinitrc script handle it...by default:
if your uid is 0 then you throw up a hate-filled messaged and
exit....by default
EOD.... by default
I'll grant you that there are some bizarro pieces of software out
there, but if they require you to be logged into X as root, that
software has to be considered at the very least buggy if not
malicious. But I see nothing wrong with making the default settings
for gdm revoke all root user attempts at logging in..by default. And I
see no problem taking a more aggressive stance by hardcoding a well
commented root login check into xinitrc that anyone who wants to break
the no root login must find and comment out. As a local admin, you
would still have the choice to reconfigure gdm or the xinitrc script
to lift those defaults.
If you have such a security fetish then go play with firewall rules
in
the corner and leave us users to decide how to operate our machines !
No, security is a community wide problem. As we learn every day,
insecurely admined boxes on the public internet can cause problems for
everyone and not just the person with the hacked box who doesn't take
the time or have the patience to do things securely. Security, sir, is
everyone's problem. And I'd much rather see buggy graphical software
fixed so that it doesn't require root login, than to have someone
inexperienced(who doesn't have the skill to even reconfigure a shell
script like xinitrc to enable root login) think that loginning into as
root is an acceptible workaround for common problems.
-jef"why won't the red sox lose gracefully..why do they have to put up
a fight"spaleta
8:09 a.m.
On Tue, 2004-10-19 at 02:12, Jeff Spaleta wrote:
On Tue, 19 Oct 2004 01:44:26 +0100, Jonathan Andrews
<jon(a)jonshouse.co.uk> wrote:
> Bite me !
Tell me where i get in line.
> Users should have the power to choose, even if you personally think its
> a poor choice.
Choose what? Choose to use less secure defaults? Choose to recompile
software using less secure settings? Choose to write their own
software?
Here let me reparse what seth said with my "by default" clause
post-processor and see if you can stomach my version:
Disable root graphical logins..... by default
Period.
make it so gdm or kdm or xdm just exit... by default
hell, you could make the xinitrc script handle it...by default:
if your uid is 0 then you throw up a hate-filled messaged and
exit....by default
EOD.... by default
I'll grant you that there are some bizarro pieces of software out
there, but if they require you to be logged into X as root, that
software has to be considered at the very least buggy if not
malicious. But I see nothing wrong with making the default settings
for gdm revoke all root user attempts at logging in..by default. And I
see no problem taking a more aggressive stance by hardcoding a well
commented root login check into xinitrc that anyone who wants to break
the no root login must find and comment out. As a local admin, you
would still have the choice to reconfigure gdm or the xinitrc script
to lift those defaults.
> If you have such a security fetish then go play with firewall rules in
> the corner and leave us users to decide how to operate our machines !
No, security is a community wide problem. As we learn every day,
insecurely admined boxes on the public internet can cause problems for
everyone and not just the person with the hacked box who doesn't take
the time or have the patience to do things securely. Security, sir, is
everyone's problem. And I'd much rather see buggy graphical software
fixed so that it doesn't require root login, than to have someone
inexperienced(who doesn't have the skill to even reconfigure a shell
script like xinitrc to enable root login) think that loginning into as
root is an acceptible workaround for common problems.
I think you simply miss my point.
Ok, so yet another Unix security person with the attitude that "mummy
knows best".
Those who are learning will WANT to login as root to configure, its the
way they think it should work - they are going to look lost and confused
if you start shipping things with defaults that stop them.
As for pop ups with "Don't do this, its naughty" - BAHHH !!! DONT !!! On
the one hand we have security people trying to take out things people
need, on the other we have the GUI people trying to put in more
pointless crap.
Those who want better security will configure things for it, however
some people don't want to know.
I for example have a number of systems that use X servers to display
status information and video. At one point I thought I was going to have
to re-write the whole thing next time I upgraded because some security
minded person at Xfree decided that removing the "-ac" option from the X
server is "more secure"
Don't force users who want a media player in the living room, or just
want to have a play with linux to behave like administrators. A lot of
home users run with almost no security at all - worry about the network
cable not the physical machine......
Jon
8:50 a.m.
So, it's not Friday yet...
On Tue, 2004-10-19 at 14:09 +0100, Jonathan Andrews wrote:
On Tue, 2004-10-19 at 02:12, Jeff Spaleta wrote:
> On Tue, 19 Oct 2004 01:44:26 +0100, Jonathan Andrews
> <jon(a)jonshouse.co.uk> wrote:
> > Bite me !
>
> Tell me where i get in line.
>
> > Users should have the power to choose, even if you personally think its
> > a poor choice.
>
> Choose what? Choose to use less secure defaults? Choose to recompile
> software using less secure settings? Choose to write their own
> software?
>
> Here let me reparse what seth said with my "by default" clause
> post-processor and see if you can stomach my version:
>
> Disable root graphical logins..... by default
> Period.
> make it so gdm or kdm or xdm just exit... by default
> hell, you could make the xinitrc script handle it...by default:
> if your uid is 0 then you throw up a hate-filled messaged and
> exit....by default
> EOD.... by default
>
> I'll grant you that there are some bizarro pieces of software out
> there, but if they require you to be logged into X as root, that
> software has to be considered at the very least buggy if not
> malicious. But I see nothing wrong with making the default settings
> for gdm revoke all root user attempts at logging in..by default. And I
> see no problem taking a more aggressive stance by hardcoding a well
> commented root login check into xinitrc that anyone who wants to break
> the no root login must find and comment out. As a local admin, you
> would still have the choice to reconfigure gdm or the xinitrc script
> to lift those defaults.
>
> > If you have such a security fetish then go play with firewall rules in
> > the corner and leave us users to decide how to operate our machines !
>
> No, security is a community wide problem. As we learn every day,
> insecurely admined boxes on the public internet can cause problems for
> everyone and not just the person with the hacked box who doesn't take
> the time or have the patience to do things securely. Security, sir, is
> everyone's problem. And I'd much rather see buggy graphical software
> fixed so that it doesn't require root login, than to have someone
> inexperienced(who doesn't have the skill to even reconfigure a shell
> script like xinitrc to enable root login) think that loginning into as
> root is an acceptible workaround for common problems.
I think you simply miss my point.
Ok, so yet another Unix security person with the attitude that "mummy
knows best".
Those who are learning will WANT to login as root to configure, its the
way they think it should work - they are going to look lost and confused
if you start shipping things with defaults that stop them.
I think we all agree that regarding security the human factor is the
weakest point in the equation. You need to get these points across:
- that regular updating is a good thing, to achieve that you make
updating easy for the user (yum, up2date, apt, ...)
- that regularly working as an ordinary user instead of always as root
is a good measure to make it harder for viruses, dialers, etc.;
As for pop ups with "Don't do this, its naughty" -
BAHHH !!! DONT !!! On
the one hand we have security people trying to take out things people
need, on the other we have the GUI people trying to put in more
pointless crap.
"Informing users about risks they're exposing themselves to is a bad
thing" -- do you really want anyone to believe that?
I guess something like:
"""
Logging in as root is not encouraged because:
- ... viruses ...
- ... dialers ...
- ... yadda yadda yadda
You can just run the configuration tools from your normal user login, or
switch temporarily to root by ... (explain su, sudo, ...)
"""
won't be taken as patronizing.
Those who want better security will configure things for it, however
some people don't want to know.
We basically have two choices:
- Making the system "easy" while at the same time making compromises on
security. This is what Windows does.
- Making the system as secure as we can get it while still allowing the
user to do the things he wants to do. That is what we try to achieve.
You really want to vote for the first option? I guess you're in the
minority then ;-).
I for example have a number of systems that use X servers to display
status information and video. At one point I thought I was going to have
to re-write the whole thing next time I upgraded because some security
minded person at Xfree decided that removing the "-ac" option from the X
server is "more secure"
I haven't needed that option, so why should you?
Don't force users who want a media player in the living room, or
just
want to have a play with linux to behave like administrators. A lot of
home users run with almost no security at all - worry about the network
cable not the physical machine......
As we're still lacking the make_this_machine_a_media_appliance-1.0-1.rpm
package, we can safely (securely? ;-) assume that the person who wants
to do that needs to fiddle a good deal anyway so editing gdm.conf or
similar files isn't to onerous IMO.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
9:10 a.m.
On Tue, 2004-10-19 at 14:50, Nils Philippsen wrote:
So, it's not Friday yet...
On Tue, 2004-10-19 at 14:09 +0100, Jonathan Andrews wrote:
> On Tue, 2004-10-19 at 02:12, Jeff Spaleta wrote:
> > On Tue, 19 Oct 2004 01:44:26 +0100, Jonathan Andrews
> > <jon(a)jonshouse.co.uk> wrote:
> > > Bite me !
> >
> > Tell me where i get in line.
> >
> > > Users should have the power to choose, even if you personally think its
> > > a poor choice.
> >
> > Choose what? Choose to use less secure defaults? Choose to recompile
> > software using less secure settings? Choose to write their own
> > software?
> >
> > Here let me reparse what seth said with my "by default" clause
> > post-processor and see if you can stomach my version:
> >
> > Disable root graphical logins..... by default
> > Period.
> > make it so gdm or kdm or xdm just exit... by default
> > hell, you could make the xinitrc script handle it...by default:
> > if your uid is 0 then you throw up a hate-filled messaged and
> > exit....by default
> > EOD.... by default
> >
> > I'll grant you that there are some bizarro pieces of software out
> > there, but if they require you to be logged into X as root, that
> > software has to be considered at the very least buggy if not
> > malicious. But I see nothing wrong with making the default settings
> > for gdm revoke all root user attempts at logging in..by default. And I
> > see no problem taking a more aggressive stance by hardcoding a well
> > commented root login check into xinitrc that anyone who wants to break
> > the no root login must find and comment out. As a local admin, you
> > would still have the choice to reconfigure gdm or the xinitrc script
> > to lift those defaults.
> >
> > > If you have such a security fetish then go play with firewall rules in
> > > the corner and leave us users to decide how to operate our machines !
> >
> > No, security is a community wide problem. As we learn every day,
> > insecurely admined boxes on the public internet can cause problems for
> > everyone and not just the person with the hacked box who doesn't take
> > the time or have the patience to do things securely. Security, sir, is
> > everyone's problem. And I'd much rather see buggy graphical software
> > fixed so that it doesn't require root login, than to have someone
> > inexperienced(who doesn't have the skill to even reconfigure a shell
> > script like xinitrc to enable root login) think that loginning into as
> > root is an acceptible workaround for common problems.
>
> I think you simply miss my point.
>
> Ok, so yet another Unix security person with the attitude that "mummy
> knows best".
>
> Those who are learning will WANT to login as root to configure, its the
> way they think it should work - they are going to look lost and confused
> if you start shipping things with defaults that stop them.
I think we all agree that regarding security the human factor is the
weakest point in the equation. You need to get these points across:
- that regular updating is a good thing, to achieve that you make
updating easy for the user (yum, up2date, apt, ...)
- that regularly working as an ordinary user instead of always as root
is a good measure to make it harder for viruses, dialers, etc.;
> As for pop ups with "Don't do this, its naughty" - BAHHH !!! DONT !!!
On
> the one hand we have security people trying to take out things people
> need, on the other we have the GUI people trying to put in more
> pointless crap.
"Informing users about risks they're exposing themselves to is a bad
thing" -- do you really want anyone to believe that?
I guess something like:
"""
Logging in as root is not encouraged because:
- ... viruses ...
- ... dialers ...
- ... yadda yadda yadda
You can just run the configuration tools from your normal user login, or
switch temporarily to root by ... (explain su, sudo, ...)
"""
won't be taken as patronizing.
> Those who want better security will configure things for it, however
> some people don't want to know.
We basically have two choices:
- Making the system "easy" while at the same time making compromises on
security. This is what Windows does.
- Making the system as secure as we can get it while still allowing the
user to do the things he wants to do. That is what we try to achieve.
You really want to vote for the first option? I guess you're in the
minority then ;-)
Its not a question of easy ! Its a question of arrogance .... your
argument is that because you know its a bad idea people should not be
able to do it. Ok - I could live with a warning .... even better if it
only happens the first time root logs in, but disabling root logins in X
is only going to cause problems, unless you can get every other distro
to follow suite .....
> I for example have a number of systems that use X servers to display
> status information and video. At one point I thought I was going to have
> to re-write the whole thing next time I upgraded because some security
> minded person at Xfree decided that removing the "-ac" option from the X
> server is "more secure"
I haven't needed that option, so why should you?
This is a windup right ? Because you personally have never needed it it
should not exist, you have been in Unix to long ........
> Don't force users who want a media player in the living
room, or just
> want to have a play with linux to behave like administrators. A lot of
> home users run with almost no security at all - worry about the network
> cable not the physical machine......
As we're still lacking the make_this_machine_a_media_appliance-1.0-1.rpm
package, we can safely (securely? ;-) assume that the person who wants
to do that needs to fiddle a good deal anyway so editing gdm.conf or
similar files isn't to onerous IMO.
I see situations like this.
novice user 1 - "how do I configure N",
novice user 2 - "log in as root and run this GUI tool"
novice user 1 - "It wont let me"
novice user 2 - "My machine does ?"
etc etc etc etc
Makes we wonder what userbase fedora is aimed at ? Should home users be
using Debian - if so who fedora for ?
As we're still lacking the
make_this_machine_a_media_appliance-1.0-1.rpm
package
Bzzz ... wrong !!!
I know a reasonable number of users who are using fedora for exactly
that. The apt repositories contain a good version of mplayer and Xine
with the common codecs. Install those and click a divx,xvid,mp3 and one
media player - with no annoying pop ups during playback. I have a box
under my TV exactly for this :-)
I suppose you want to pop-up a window in xine now saying "Playing this
video while logged in as root is a security risk"
Jon
9:32 a.m.
On Tue, 2004-10-19 at 15:10 +0100, Jonathan Andrews wrote:
On Tue, 2004-10-19 at 14:50, Nils Philippsen wrote:
snip... (try cutting down the mails here people)
> We basically have two choices:
>
> - Making the system "easy" while at the same time making compromises on
> security. This is what Windows does.
> - Making the system as secure as we can get it while still allowing the
> user to do the things he wants to do. That is what we try to achieve.
>
> You really want to vote for the first option? I guess you're in the
> minority then ;-)
Its not a question of easy ! Its a question of arrogance .... your
argument is that because you know its a bad idea people should not be
able to do it. Ok - I could live with a warning .... even better if it
only happens the first time root logs in, but disabling root logins in X
is only going to cause problems, unless you can get every other distro
to follow suite .....
If you are experienced enough to have a reason to run anything as root,
you are experienced enough to click the checkbox in the GDM
configuration to turn root logins back on.
Many other home-user oriented distros disable root logins, or even get
rid of the entire account at all.
> As we're still lacking the
make_this_machine_a_media_appliance-1.0-1.rpm
> package, we can safely (securely? ;-) assume that the person who wants
> to do that needs to fiddle a good deal anyway so editing gdm.conf or
> similar files isn't to onerous IMO.
I see situations like this.
novice user 1 - "how do I configure N",
novice user 2 - "log in as root and run this GUI tool"
novice user 1 - "It wont let me"
novice user 2 - "My machine does ?"
etc etc etc etc
So the problem is you have two novices, neither of which know what the
hell they're doing, running into problems caused by differences by using
two completely different operating systems? (I don't care if they have
the same kernel or glibc or anything, those are teensy minor bits of
what makes an OS.)
Nothing stops the users from running GUI tools as root. The
configuration tools in Fedora will *still* run as root. They'll still
popup and ask for a password. (Either the root password, or the user's
password using the SELinux roles mechanism or sudo.)
If a user needs to run a tool as root, they can log in as their user and
use su or sudo. Simple. It can even be a graphical tool. It Just
Works(tm). Not to mention it's a hell of a lot more convenient than
logging in as a whole different user at the login screen again.
Makes we wonder what userbase fedora is aimed at ? Should home users be
using Debian - if so who fedora for ?
*snort* Debian. For home users. Riiiight. ;-)
I suppose you want to pop-up a window in xine now saying "Playing this
video while logged in as root is a security risk"
YES! These are apps that often use Windows DLLs and/or very complex
codec libraries that have had zero code review or testing. It is
absolutely moronic to be running random movies you get as fricken' root.
There's *no* reason at all that xine can't play the same videos as a
normal user.
If your PVR is configured to run things as root, you misconfigured your
box. It is flat out stupid and it's perfectly good that the OS tries to
stop you. Then maybe you'll go online, look for help, and find the
documentation telling you how to configure the box intelligently.
Jon
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
9:40 a.m.
Jonathan Andrews wrote:
I see situations like this.
novice user 1 - "how do I configure N",
novice user 2 - "log in as root and run this GUI tool"
novice user 1 - "It wont let me"
novice user 2 - "My machine does ?"
etc etc etc etc
You don't need to log in as root to run a GUI tool as root.
Makes we wonder what userbase fedora is aimed at ? Should home users
be
using Debian - if so who fedora for ?
Well, have you considered that maybe the situation you are describing is
not that common for most home users? I'm not saying it is or it isn't...
but I'm not the one wondering whether fedora is aimed at home users
based on what could possibly be a special cases.
Should I complaing that Fedora is not friendly to gamers because I need
to be aware of performance and security issues in order to run a "insert
your favorite game here" dedicated server?
Regards,
Ricardo Veguilla
10:09 a.m.
On Tue, 2004-10-19 at 15:40, Ricardo Veguilla wrote:
Jonathan Andrews wrote:
You don't need to log in as root to run a GUI tool as root.
True
>Makes we wonder what userbase fedora is aimed at ? Should home users be
>using Debian - if so who fedora for ?
>
>
Well, have you considered that maybe the situation you are describing is
not that common for most home users? I'm not saying it is or it isn't...
but I'm not the one wondering whether fedora is aimed at home users
based on what could possibly be a special cases.
Its partly out of date on my part,
xine didn't used to play properly as
non-root. Similar with some of the firewire applications.
Its not common, but I see a dangerous trend amongst security people to
stamp down hard on anything thats insecure without thinking it through
for all users and workloads.
It would be good to discourage people from surfing as root, but at the
same time it would be bad to stop people logging into X as root. Users
have the right to be stupid......
Should I complaing that Fedora is not friendly to gamers because I
need
to be aware of performance and security issues in order to run a "insert
your favorite game here" dedicated server?
This tread has degraded, I was originally answering a comment that
xdm,gdm,kdm should have root logins disabled. Not an "option" to
disable/enabled... but remove the possibility of loggining in as root
without first editing xinit scripts. I just wanted it noted that from a
user perspective this was arrogant !
Jon
12:34 p.m.
tir, 19.10.2004 kl. 17.09 skrev Jonathan Andrews:
On Tue, 2004-10-19 at 15:40, Ricardo Veguilla wrote:
> Jonathan Andrews wrote:
> You don't need to log in as root to run a GUI tool as root.
True
>
> >Makes we wonder what userbase fedora is aimed at ? Should home users be
> >using Debian - if so who fedora for ?
> >
> >
> Well, have you considered that maybe the situation you are describing is
> not that common for most home users? I'm not saying it is or it isn't...
> but I'm not the one wondering whether fedora is aimed at home users
> based on what could possibly be a special cases.
Its partly out of date on my part, xine didn't used to play properly as
non-root. Similar with some of the firewire applications.
Its not common, but I see a dangerous trend amongst security people to
stamp down hard on anything thats insecure without thinking it through
for all users and workloads.
It would be good to discourage people from surfing as root, but at the
same time it would be bad to stop people logging into X as root. Users
have the right to be stupid......
> Should I complaing that Fedora is not friendly to gamers because I need
> to be aware of performance and security issues in order to run a "insert
> your favorite game here" dedicated server?
This tread has degraded, I was originally answering a comment that
xdm,gdm,kdm should have root logins disabled. Not an "option" to
disable/enabled... but remove the possibility of loggining in as root
without first editing xinit scripts. I just wanted it noted that from a
user perspective this was arrogant !
I agree. Make it an option in gdmsetup, or even better, make some kind
of nice little "warning" box popup at startup. This box should contain a
short, informative text, an "OK" button, an "OK, log me out" button,
and
a "please don't show me this again".
Did you knew that one of the things that really pissed me off and away
from windows, is that, while running as an administrator, got an "access
denied" when trying to enter a (some kind of special, found it in a
config file and was curious) well-hidden directory.
Jon
12:57 p.m.
On Tue, Oct 19, 2004 at 07:34:48PM +0200, Kyrre Ness Sjobak wrote:
I agree. Make it an option in gdmsetup, or even better, make some
kind
of nice little "warning" box popup at startup. This box should contain a
short, informative text, an "OK" button, an "OK, log me out" button,
and
a "please don't show me this again".
I don't think it should have "please don't show me this again" --
that's too
easy to click without really thinking. One should have to know what they're
doing to disable it.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:19 p.m.
tir, 19.10.2004 kl. 19.57 skrev Matthew Miller:
On Tue, Oct 19, 2004 at 07:34:48PM +0200, Kyrre Ness Sjobak wrote:
> I agree. Make it an option in gdmsetup, or even better, make some kind
> of nice little "warning" box popup at startup. This box should contain a
> short, informative text, an "OK" button, an "OK, log me out"
button, and
> a "please don't show me this again".
I don't think it should have "please don't show me this again" --
that's too
easy to click without really thinking. One should have to know what they're
doing to disable it.
If the user does that, that is indeed the users problem. If the user
wants to kill his/her box with a shotgun (i heard sombody did that to an
old (not then, but...) mac when it didn't do as she told it to...), they
are in their full right to do so.
And to sombody who said that "computers are designed to be usefull not
secure" is the same as "computers are not meant to be secure" - i
interprited that as "computers are made to be both usefull and secure".
Anyway, how much is a computer that the user cant use because it is to
tigthly locked up, worth? Why dont we remove tcp/ip altogether? Or
simply the kernel? If the user cant boot it, then it is *really* secure.
And make it forget all data that is saved to disk, just to make sure
that it cant be read later by somebody evil?
Security can go to far. I do not think security is a bad thing - i just
think that it should not get in the way when it is not nesessary.
Kyrre
1:40 p.m.
On Tue, 2004-10-19 at 20:19 +0200, Kyrre Ness Sjobak wrote:
And to sombody who said that "computers are designed to be
usefull not
secure" is the same as "computers are not meant to be secure" - i
interprited that as "computers are made to be both usefull and secure".
Anyway, how much is a computer that the user cant use because it is to
tigthly locked up, worth? Why dont we remove tcp/ip altogether? Or
simply the kernel? If the user cant boot it, then it is *really* secure.
And make it forget all data that is saved to disk, just to make sure
that it cant be read later by somebody evil?
Disabling root login in GDM *does not stop the computer from doing
anything useful* !! There are far more secure and far more convenient
ways to perform any administration/configuration task or running any
"requires root" program than logging in as root at GDM.
I'm completely for axing the root account altogether. And you know
what? It isn't going to stop a single thing I want to do with my
computer, or a single thing *you* want to do with your computer. All
it's going to do is make you have to do things using a better, albeit
different, method than you used before.
Removing root logins from GDM will *not* cause any application to stop
working or any task to become impossible. It just stops root logins
from GDM. Quit confusing the problem (how to run tasks that require
root) with one solution (logging in as root at GDM).
There are other solutions that are safer *and* more convenient. Fedora
already employs them. They're called "consolehelper", "su", and
"sudo".
Graphical versions of su and sudo also exist, for users that want a
graphical "runas" mechanism.
Security can go to far. I do not think security is a bad thing - i just
think that it should not get in the way when it is not nesessary.
Just like root should not get in the way when it's not necessary. It
isn't necessary to log into root as GDM spawning an entire root desktop
session when all you need to do is run some particular tools with
elevated privileges. You can run those same tools with the same
elevated privileges after logging into a user account or switching to a
text console.
Kyrre
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
1:54 p.m.
On Tue, Oct 19, 2004 at 08:19:10PM +0200, Kyrre Ness Sjobak wrote:
If the user does that, that is indeed the users problem. If the user
wants to kill his/her box with a shotgun (i heard sombody did that to an
old (not then, but...) mac when it didn't do as she told it to...), they
are in their full right to do so.
Yeah, but I'm concerned that this doesn't _seem_ like taking a shotgun to
the box to an uninformed user. It'll just seem like one of those nuisance
dialog boxes web browsers give you like "Warning! You are connecting to a
secure site! All of your traffic will be encrypted! [ ] Never show this
message again."
Anyway, how much is a computer that the user cant use because it is
to
tigthly locked up, worth? Why dont we remove tcp/ip altogether? Or
simply the kernel? If the user cant boot it, then it is *really* secure.
And make it forget all data that is saved to disk, just to make sure
that it cant be read later by somebody evil?
This reduction can go the other way. Why set a root password during the
install? Why not just have all of the services preconfigured and running
wide open to the internet? Why not make everything mode 777?
Security can go to far. I do not think security is a bad thing - i
just
think that it should not get in the way when it is not nesessary.
In this case, it's not getting in the way. There's no reason to need to log
in to X as root. (The need to run the authconfig X gui is a special case,
and can be resolved by either using the text-mode tools, or by getting a
proper fix to <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55193>.)
(If you're really concerned about this in an enterprise environment, having
a non-root local account with a UID < 100 may be a good idea. But it's not
necessary in the general case.)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
2:41 p.m.
Le mardi 19 octobre 2004 à 20:19 +0200, Kyrre Ness Sjobak a écrit :
Anyway, how much is a computer that the user cant use because it is
to
tigthly locked up, worth? Why dont we remove tcp/ip altogether? Or
simply the kernel? If the user cant boot it, then it is *really* secure.
And make it forget all data that is saved to disk, just to make sure
that it cant be read later by somebody evil?
Security can go to far. I do not think security is a bad thing - i just
think that it should not get in the way when it is not nesessary.
Security is not something you bolt on as an afterthought. You get
security by putting it in the picture from day one, and accepting it
will cost you in terms of features at first because the time spent on
security won't be spent elsewhere.
If you can't accept the compromises security forces on you because of
the inconvenience, then you *will* have to do stupid radical measures
like removing networking to get your security certification later.
I'm all for measures like deprecating root and gradually remove any
incentive to do things the insecure way. It's way better than doing an
hatchet job the day you realise that because of all the slightly
inconvenient decisions that were never taken your security model is
about to collapse (The periodic app mass extinctions windows suffers are
a good example. The two last ones were named windows 2000 and XP SP2 I
think)
--
Nicolas Mailhot
9:52 a.m.
Jonathan Andrews wrote:
Its not a question of easy ! Its a question of arrogance .... your
argument is that because you know its a bad idea people should not be
able to do it. Ok - I could live with a warning .... even better if it
only happens the first time root logs in, but disabling root logins in X
is only going to cause problems, unless you can get every other distro
to follow suite .....
It is a bad idea and because many users that migrate over view root as
just another user with more power and fewer nags it is a good idea to
set system defaults that encourage them to operate the user correctly.
Others will follow suit. Quite honesty it doenst matter what "you" can
live with. The goals of defaults is to encompass the needs and
preferences of the largest aspect of the user base. I can respect that
you think the changes will make your life less convienant but it will in
fact be a good change for most users, especially as more migrate over
from microsoft based OSes.
novice user 1 - "how do I configure N",
novice user 2 - "log in as root and run this GUI tool"
novice user 1 - "It wont let me"
novice user 2 - "My machine does ?"
etc etc etc etc
Blind leading the blind? I dont care how convienant the distro is this
will cause trouble.
Personal insults are unwelcome and often sign of a weak argument. I
believe Fedora's desktop (gnome) will have to simplify, unify, and baby
proof itself to a great degree in the coming months and years if it is
to be a success . In most cases this wont result in a loss of
functionality but if the situation is grave enough it may be justified
to do so. In this case it isnt a problem or an issue. I can understand
that you may view this as a neutering but ask that you understand that
is it is the best interest of the distribution in the long run.
-mf
10:22 a.m.
Personal insults are unwelcome and often sign of a weak argument.
Not being from the USA I assumed "bite me" was only of slight offence.
Guess I was wrong, sorry to all offended !
I
believe Fedora's desktop (gnome) will have to simplify, unify, and baby
proof itself to a great degree in the coming months and years if it is
to be a success . In most cases this wont result in a loss of
functionality but if the situation is grave enough it may be justified
to do so. In this case it isnt a problem or an issue. I can understand
that you may view this as a neutering but ask that you understand that
is it is the best interest of the distribution in the long run.
Where does it end ... more wizards and hand holding, small animated
characters to help guide people through, while at the same time removing
anything sharp so users don't cut themselves?
I can understand telling users running X as root is bad, but removing
the ability to do so seems a bit nanny.
Jon
10:22 a.m.
Where does it end ... more wizards and hand holding, small animated
characters to help guide people through, while at the same time removing
anything sharp so users don't cut themselves?
I can understand telling users running X as root is bad, but removing
the ability to do so seems a bit nanny.
Removing the ability to do so, by default.
NOT removing the ability forever.
I don't want to see an upstream checkin of xorg-x11 that removes root-
run access.
but I'd love for fedora core 4 to point and laugh at you if you try to
login as root w/o modifying the defaults.
-sv
5:37 p.m.
On Tue, Oct 19, 2004 at 11:22:40AM -0400, seth vidal wrote:
> Where does it end ... more wizards and hand holding, small animated
> characters to help guide people through, while at the same time removing
> anything sharp so users don't cut themselves?
>
> I can understand telling users running X as root is bad, but removing
> the ability to do so seems a bit nanny.
>
Removing the ability to do so, by default.
I agree with that. Gdm has (had?) an "AllowRoot" option that should be
enough. A user can always go to a text console and do a manual "startx",
and I'm not against allowing that.
Regards,
Luciano Rocha
--
Consciousness: that annoying time between naps.
10:51 a.m.
On Tue, 2004-10-19 at 15:10 +0100, Jonathan Andrews wrote:
On Tue, 2004-10-19 at 14:50, Nils Philippsen wrote:
> So, it's not Friday yet...
[...]
> We basically have two choices:
>
> - Making the system "easy" while at the same time making compromises on
> security. This is what Windows does.
> - Making the system as secure as we can get it while still allowing the
> user to do the things he wants to do. That is what we try to achieve.
>
> You really want to vote for the first option? I guess you're in the
> minority then ;-)
Its not a question of easy ! Its a question of arrogance .... your
argument is that because you know its a bad idea people should not be
able to do it. Ok - I could live with a warning .... even better if it
only happens the first time root logs in, but disabling root logins in X
is only going to cause problems, unless you can get every other distro
to follow suite .....
Disabling root login as a configuration option isn't near arrogant. If
they're able to edit gdm.conf/run gdm configurator, they're able to
login as root. Hopefully by that point they're able to see that it isn't
a brilliant idea anyway ;-).
>
> > I for example have a number of systems that use X servers to display
> > status information and video. At one point I thought I was going to have
> > to re-write the whole thing next time I upgraded because some security
> > minded person at Xfree decided that removing the "-ac" option from
the X
> > server is "more secure"
>
> I haven't needed that option, so why should you?
This is a windup right ? Because you personally have never needed it it
should not exist, you have been in Unix to long ........
This was my "I frankly don't care that it isn't Friday" line ;-).
Seriously, I have done quite some things with X and never had to resort
to this option, so I asked myself why you needed it.
> > Don't force users who want a media player in the living
room, or just
> > want to have a play with linux to behave like administrators. A lot of
> > home users run with almost no security at all - worry about the network
> > cable not the physical machine......
>
> As we're still lacking the make_this_machine_a_media_appliance-1.0-1.rpm
> package, we can safely (securely? ;-) assume that the person who wants
> to do that needs to fiddle a good deal anyway so editing gdm.conf or
> similar files isn't to onerous IMO.
I see situations like this.
novice user 1 - "how do I configure N",
novice user 2 - "log in as root and run this GUI tool"
novice user 1 - "It wont let me"
Meep:
novice user 1: "It says I can do this as a normal user as well"
novice user 2: "Huh?"
;-)
> As we're still lacking the
make_this_machine_a_media_appliance-1.0-1.rpm
> package
Bzzz ... wrong !!!
I know a reasonable number of users who are using fedora for exactly
that. The apt repositories contain a good version of mplayer and Xine
with the common codecs. Install those and click a divx,xvid,mp3 and one
media player - with no annoying pop ups during playback. I have a box
under my TV exactly for this :-)
Still you need to glue together many parts, tweak many settings, and
nothing you tell me needs to be done as root.
I suppose you want to pop-up a window in xine now saying
"Playing this
video while logged in as root is a security risk"
A good idea given the reasons others pointed out on this thread ;-).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
8:16 p.m.
Jonathan Andrews wrote:
>Disable root graphical logins.
>
>Period.
>
>make it so gdm or kdm or xdm just exit.
>
>hell, you could make the xinitrc script handle it:
>
>if your uid is 0 then you throw up a hate-filled messaged and exit.
>
>EOD.
>
>If you can't flip to a console and take care of the problem there as
>root, then you REALLY don't need to be logged into a graphical client to
>do it.
>
>
Bite me !
Calm down. Being an ass isn't going to make anyone want to listen to your
point of view. Just the opposite, in fact.
For the record, just because Fedora by default might ship with the GDM
option to disable root logins, nothing stops you from changing that
option on your own systems.
I want to run some of my boxes as root with X, not to mention the
problems this would cause trying to work with some cluster setups and
embedded boxes. I have X code then even requires to run UID 0.
Users should have the power to choose, even if you personally think its
a poor choice.
You always have the power to choose another distribution. Just because
a choice exists doesn't mean it should be encouraged. Everyone has the
choice to open up telnet with root login allowed and no password.
Doesn't mean we make that the default. For good reason, of course.
If you have such a security fetish then go play with firewall rules
in
the corner and leave us users to decide how to operate our machines !
If you have such a control fetish then go play with LFS in the corner
and leave the Fedora developers to decide how to develop their
distribution !
Jon
10:39 p.m.
>>Disable root graphical logins.
>>
>>Period.
>>
>>make it so gdm or kdm or xdm just exit.
>>
>>hell, you could make the xinitrc script handle it:
>>
>>if your uid is 0 then you throw up a hate-filled messaged and exit.
>>
>>EOD.
>>
>>If you can't flip to a console and take care of the problem there as
>>root, then you REALLY don't need to be logged into a graphical client to
>>do it.
>>
>>
>Bite me !
No... as others have said disabling a feature by *default* does not
in
and of itself make it impossible for an OP to edit /etc/whatever.conf
to enable root's logging into a graphical environment. It *does*
impose a sensible default (for most people), which in turn should
encourage the teeming_masses(tm) to avoid high risk behavior w/o at
least thinking it through first. Note that there are already some
linux distros out there, not naming names, where the whole pesky user
stuff has been eliminated altogether. Those simply default to root.
IMHO we don't want to go there either, the windows 98/XP/2000 style
admin / power user defaults have caused enough damage already. Given
the choice & sensible defaults most users / OPs will do the right
thing. The trick is leading them towards that especially where windows
refugees are concerned.
Like it or not a significant portion of linix users are, in fact,
coming from a predominantly windows background. Either way default
behaviors should reflect best practices whether defined as the most
intuitive (e.g. nautilus bringing up a burn window when blank CD media
is inserted) or most secure (ftp is not installed/enabled by default,
right).
People who have other preferences / special needs can & *should* alter
the defaults accordingly to suit their needs.
--
Bests,
JS
10:44 a.m.
I had a very good reason to login as root some days ago. In gui.
The LDAP system collapsed (or, more consicely, it somehow beginned to
take 5 minutes to get a GNOME login (where 5-10 sec is normal...). So, i
logged in as root, ran system-config-authentification, turned on user
info cacheing, logged back out, and things worked.
tir, 19.10.2004 kl. 05.39 skrev Jon Savage:
> >>Disable root graphical logins.
> >>
> >>Period.
> >>
> >>make it so gdm or kdm or xdm just exit.
> >>
> >>hell, you could make the xinitrc script handle it:
> >>
> >>if your uid is 0 then you throw up a hate-filled messaged and exit.
> >>
> >>EOD.
> >>
> >>If you can't flip to a console and take care of the problem there as
> >>root, then you REALLY don't need to be logged into a graphical client
to
> >>do it.
> >>
> >>
> >Bite me !
No... as others have said disabling a feature by *default* does not in
and of itself make it impossible for an OP to edit /etc/whatever.conf
to enable root's logging into a graphical environment. It *does*
impose a sensible default (for most people), which in turn should
encourage the teeming_masses(tm) to avoid high risk behavior w/o at
least thinking it through first. Note that there are already some
linux distros out there, not naming names, where the whole pesky user
stuff has been eliminated altogether. Those simply default to root.
IMHO we don't want to go there either, the windows 98/XP/2000 style
admin / power user defaults have caused enough damage already. Given
the choice & sensible defaults most users / OPs will do the right
thing. The trick is leading them towards that especially where windows
refugees are concerned.
Like it or not a significant portion of linix users are, in fact,
coming from a predominantly windows background. Either way default
behaviors should reflect best practices whether defined as the most
intuitive (e.g. nautilus bringing up a burn window when blank CD media
is inserted) or most secure (ftp is not installed/enabled by default,
right).
People who have other preferences / special needs can & *should* alter
the defaults accordingly to suit their needs.
--
Bests,
JS
10:48 a.m.
On Tue, 2004-10-19 at 17:44 +0200, Kyrre Ness Sjobak wrote:
I had a very good reason to login as root some days ago. In gui.
The LDAP system collapsed (or, more consicely, it somehow beginned to
take 5 minutes to get a GNOME login (where 5-10 sec is normal...). So, i
logged in as root, ran system-config-authentification, turned on user
info cacheing, logged back out, and things worked.
ctrl-alt-f1
login as root
chkconfig nscd on
service nscd start
logout
alt-f7
-sv
10:56 a.m.
Kyrre Ness Sjobak wrote:
I had a very good reason to login as root some days ago. In gui.
The LDAP system collapsed (or, more consicely, it somehow beginned to
take 5 minutes to get a GNOME login (where 5-10 sec is normal...). So, i
logged in as root, ran system-config-authentification, turned on user
info cacheing, logged back out, and things worked.
what's wrong with logging as any unprivileged user, to open a xterm,
to run "su -" and then system-config-authentification ?
--
Hello, this is Darl McBride, and I pronounce Linux as UNIX.
11:19 a.m.
On Tue, Oct 19, 2004 at 05:56:31PM +0200, Xose Vazquez Perez wrote:
>The LDAP system collapsed (or, more consicely, it somehow
beginned to
>take 5 minutes to get a GNOME login (where 5-10 sec is normal...). So, i
>logged in as root, ran system-config-authentification, turned on user
>info cacheing, logged back out, and things worked.
what's wrong with logging as any unprivileged user, to open a xterm,
to run "su -" and then system-config-authentification ?
With LDAP down, unpriviledged users couldn't authenticate.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:52 p.m.
Matthew Miller wrote:
On Tue, Oct 19, 2004 at 05:56:31PM +0200, Xose Vazquez Perez wrote:
>>The LDAP system collapsed (or, more consicely, it somehow beginned to
>>take 5 minutes to get a GNOME login (where 5-10 sec is normal...). So, i
>>logged in as root, ran system-config-authentification, turned on user
>>info cacheing, logged back out, and things worked.
>
>what's wrong with logging as any unprivileged user, to open a xterm,
>to run "su -" and then system-config-authentification ?
With LDAP down, unpriviledged users couldn't authenticate.
Always is a good idea to have a second user(unpriviledged) in local
for maintenance, operator or something like this.
--
Hello, this is Darl McBride, and I pronounce Linux as UNIX.
12:34 p.m.
Primarily that it would take 10 minutes per machine and i had only 5
minutes. Anyway, i *knew* the dangers, did not visit the web etc. while
doing this.
I have never heard of "nscd", but i have heard of
that-nice-litte-checkbox. That is called userfriendlyness.
tir, 19.10.2004 kl. 17.56 skrev Xose Vazquez Perez:
Kyrre Ness Sjobak wrote:
> I had a very good reason to login as root some days ago. In gui.
>
> The LDAP system collapsed (or, more consicely, it somehow beginned to
> take 5 minutes to get a GNOME login (where 5-10 sec is normal...). So, i
> logged in as root, ran system-config-authentification, turned on user
> info cacheing, logged back out, and things worked.
what's wrong with logging as any unprivileged user, to open a xterm,
to run "su -" and then system-config-authentification ?
--
Hello, this is Darl McBride, and I pronounce Linux as UNIX.
11:40 a.m.
On Tue, 2004-10-19 at 17:44 +0200, Kyrre Ness Sjobak wrote:
I had a very good reason to login as root some days ago. In gui.
The LDAP system collapsed (or, more consicely, it somehow beginned to
take 5 minutes to get a GNOME login (where 5-10 sec is normal...). So, i
logged in as root, ran system-config-authentification, turned on user
info cacheing, logged back out, and things worked.
Without GUI, there's authconfig.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
7:54 p.m.
On Tuesday 19 October 2004 08:32, seth vidal wrote:
If you can't flip to a console and take care of the problem there
as
root, then you REALLY don't need to be logged into a graphical client
to do it.
Maybe go to failsafe with just a xterm. Is that a security risk?
Also, I know things like Bastille (stripped /etc/securetty) can restrict
root from logging in even from the tty. This forces the user to login
first and switch to the root user in their session. It's another layer
of security that a cracker must go around. Of course, if a user used
NOPASSWD in sudoers, there's only one layer: the user's password.
take care,
--
-jeff
8 p.m.
seth vidal wrote:
Disable root graphical logins.
too much radical.
It's much better, IMHO, to make the X root environment 'uncomfortable'
with _minimal_ options/menus and a bad look to show people that
root's $HOME is not a good place to work everyday ;-)
I vote for twm as windowmanager for root X-D
--
Hello, this is Darl McBride, and I pronounce Linux as UNIX.
8:06 p.m.
On Mon, Oct 18, 2004 at 08:32:13PM -0400, seth vidal wrote:
> Maybe SuSE or Mandrake's scary red background if you login
as root is a
> good idea. Should we implement that for RHEL4?
Disable root graphical logins.
Period.
make it so gdm or kdm or xdm just exit.
Or do it what I do -- make it launch a minimalist environment which presents
only the user manager tool, and some text explaining how to create a normal
user with administrative access. (We also configure the wheel group with sudo
and usermode sudo-like power, but that wouldn't be strictly necessary.)
hell, you could make the xinitrc script handle it:
if your uid is 0 then you throw up a hate-filled messaged and exit.
That's what we used to do. Well, except instead of 'hate-filled', it was
educational. And there was a 'okay, let me do it anyway' button that you
could pick after 30 seconds.
EOD.
Heh.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
11:47 a.m.
On Tue, 2004-10-19 at 17:39 +0100, Manuel Moreno wrote:
On Mon, 2004-10-18 at 20:32 -0400, seth vidal wrote:
> Disable root graphical logins.
>
> Period.
>
...
> -sv
>
>
Don't do it, for God's sake!
Let's not forget that computers are to be useful *not* to be secure.
Fortunately, the computer is 100% useful without having root graphical
logins. Anyone who thinks otherwise is failing to think of the actual
problem (I need to do task X) and is instead only thinking of an old
solution (just login as root). Everything you can possibly do by
logging in as root at GDM can be done some other way, in both a more
secure *and* a more convenient manner.
--
Manuel Moreno <manolo(a)miconexion.com>
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
5:51 p.m.
Sean Middleditch wrote:
On Tue, 2004-10-19 at 17:39 +0100, Manuel Moreno wrote:
>On Mon, 2004-10-18 at 20:32 -0400, seth vidal wrote:
>
>
>>Disable root graphical logins.
>>
>>Period.
>>
>>
>>
>...
>
>
>>-sv
>>
>>
>>
>>
>Don't do it, for God's sake!
>
>Let's not forget that computers are to be useful *not* to be secure.
>
>
Fortunately, the computer is 100% useful without having root graphical
logins. Anyone who thinks otherwise is failing to think of the actual
problem (I need to do task X) and is instead only thinking of an old
solution (just login as root). Everything you can possibly do by
logging in as root at GDM can be done some other way, in both a more
secure *and* a more convenient manner.
>--
>Manuel Moreno <manolo(a)miconexion.com>
>
>
>
Actually, for my work, I use the graphical root login for one thing:
Setting up a freshly installed machine... I know that this can be done
from an user account, but I often have a lot of things that needs to be
configured as root (both with graphical and shell tools). The shell
tools isn't a problem, as a simple su - can accomplish this, but the
graphical setup tools is a different story. When using a graphical
(root-required) tool, you can run several (root) tools shortly after
each other. But after some time, you will loose the privileges again.
And then you need to use the root password yet again. This is anoying if
it happens too many times a day.
So I find the graphical root login usefull when setting up a fresh machine.
Another issue is, that a system, at install time, can be configured
without any users at all. This is for instance the case if you configure
network authentication. If this setup for some reason doesn't work, and
root cannot log in (graphically), the user is left with a system he
cannot login to. Surely he can use a graphical console, but often a
graphical login will be more usefull, since it can be easier to fix
thing. Anyway, you are able to have a webbrowser and a console on the
same screen, which I have found to be very usefull :)
However, I'm voting in favor off a warning message at log in, and
possibly some doomsday looking desktop.
Regards
/kbn
7:22 p.m.
Kim B. Nielsen wrote:
Actually, for my work, I use the graphical root login for one thing:
Setting up a freshly installed machine... I know that this can be done
from an user account, but I
Kickstart doesn't help? It's a fairly useful technology that only Red
Hat has a good implementation of. (That I'm aware of.)
Another issue is, that a system, at install time, can be configured
without any users at all. This is for instance the case if you
configure network authentication. If this setup for some reason
doesn't work, and root cannot log in (graphically), the user is left
with a system he cannot login to. Surely he can use a graphical
console, but often a graphical login will be more usefull, since it
can be easier to fix thing. Anyway, you are able to have a webbrowser
and a console on the same screen, which I have found to be very
usefull :)
But an admin can get into X even if GDM disallows it. And only an admin
is setting up machines with network authentication. It's the home users
that don't have a fricken' clue that think, "oh, I'll log in as this
root thingy, it's soooo much easier!" that are the problem.
However, I'm voting in favor off a warning message at log in, and
possibly some doomsday looking desktop.
Regards
/kbn
3:15 a.m.
Sean Middleditch wrote:
Kim B. Nielsen wrote:
>
> Actually, for my work, I use the graphical root login for one thing:
>
> Setting up a freshly installed machine... I know that this can be
> done from an user account, but I
Kickstart doesn't help? It's a fairly useful technology that only Red
Hat has a good implementation of. (That I'm aware of.)
Yes, we do use kickstarts... But that isn't really feasible on the
laptops we are installing, because the hardware is different on nearly
each one and everyone wants to be root on their laptop. Having root on
their laptop means, of course, that the laptop isn't trusted on our
network...
We are, however, using kickstarts to a large extent on our regular machines.
>
> Another issue is, that a system, at install time, can be configured
> without any users at all. This is for instance the case if you
> configure network authentication. If this setup for some reason
> doesn't work, and root cannot log in (graphically), the user is left
> with a system he cannot login to. Surely he can use a graphical
> console, but often a graphical login will be more usefull, since it
> can be easier to fix thing. Anyway, you are able to have a webbrowser
> and a console on the same screen, which I have found to be very
> usefull :)
But an admin can get into X even if GDM disallows it. And only an
admin is setting up machines with network authentication. It's the
home users that don't have a fricken' clue that think, "oh, I'll log
in as this root thingy, it's soooo much easier!" that are the problem.
True... But I think that the doomsday screen and warning message will
work better, than disallowing the graphical login. When you are setting
something up on a machine, it's sometimes easier to use the graphical
root to configure the thingy and make it work, and then, afterwards,
figure out how to make normal users use the thingy.
>
> However, I'm voting in favor off a warning message at log in, and
> possibly some doomsday looking desktop.
>
> Regards
> /kbn
>
--
"He who controls the proxy server, controls the world..."
6:30 a.m.
On Fri, 22 Oct 2004 00:51:12 +0200, Kim B. Nielsen wrote:
However, I'm voting in favor off a warning message at log in,
and
possibly some doomsday looking desktop.
Me too.
And all the programs working.
If a program like xscreensaver is not working as root, why have them in
the root's menu in the first place.
But IMO one should be able to lock the root's screen anyway.
11:48 a.m.
Manuel Moreno wrote:
On Mon, 2004-10-18 at 20:32 -0400, seth vidal wrote:
>Disable root graphical logins.
>
>Period.
>
>
>
...
>-sv
>
>
>
>
Don't do it, for God's sake!
Let's not forget that computers are to be useful *not* to be secure.
People with that attibute can go back to windows and play with their
viri and worms.
Computer should be both useful and secure.
-josh
12:40 p.m.
tir, 19.10.2004 kl. 18.48 skrev Joshua Eichorn:
Manuel Moreno wrote:
>On Mon, 2004-10-18 at 20:32 -0400, seth vidal wrote:
>
>
>>Disable root graphical logins.
>>
>>Period.
>>
>>
>>
>...
>
>
>>-sv
>>
>>
>>
>>
>
>Don't do it, for God's sake!
>
>Let's not forget that computers are to be useful *not* to be secure.
>
>
>
People with that attibute can go back to windows and play with their
viri and worms.
Computer should be both useful and secure.
-josh
Windows have stepped of the line - that should not make us step over the
line as well (albeit on the other side of it).
Lets continue to have the possibillity, but give a warning box.
4:53 a.m.
On Mon, Oct 18, 2004 at 08:27:18PM -0400, Havoc Pennington wrote:
I agree with you, fwiw. Any reason to need to log in as root is a
bug.
Then gdm is a bug 8) You need root login when things like ldap go away otherwise
you can't login. When you can fix gdm to automatically switch to telepathy mode
let me know. Similarly if the system develops problems and you need to boot
to single user you need root.
Keep to "root should not be needed in normal situations" and I'd agree
Alan
5:02 a.m.
On Thu, 2004-10-21 at 05:53 -0400, Alan Cox wrote:
On Mon, Oct 18, 2004 at 08:27:18PM -0400, Havoc Pennington wrote:
> I agree with you, fwiw. Any reason to need to log in as root is a bug.
Then gdm is a bug 8) You need root login when things like ldap go away otherwise
Although you don't necessarily need a graphical login.
you can't login. When you can fix gdm to automatically switch to
telepathy mode
let me know. Similarly if the system develops problems and you need to boot
to single user you need root.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
8:28 a.m.
On Thu, 21 Oct 2004 12:02:13 +0200, Nils Philippsen <nphilipp(a)redhat.com> wrote:
Although you don't necessarily need a graphical login.
I'm not sure I like using the argument that expects people to use a
console login in which they are unfamiliar to the tools. As more and
more wizardy Setting Setting tools get developer to ease the task of
administration on for subsystems, you have to expect less proficiency
at the commandline among admins in the userbase overall. If openldap
authing can be configured without stepping foot into consoleland,
having a way to troubleshoot common configuration failure modes of
openldap without dropping to console would seem appriopriate. The
argument isn't so much about bare minimum 'needs' to get the job done.
The argument is, adminsn especially less experienced admins, are going
to find ways to use the tools they are comfortable with to solve their
defcon 3 problems so it gets solved as quickly as possible.
With that preamble in mind.... is "best practise" with regard to
openldap or other network authing to have at least one locally authed
unprivlegded "operator" as suggested previously in this thread? If so,
are their opportunities in the ui tools in Core to strongly suggest or
strongarm if not require that such a local operator be created?
-jef
8:52 a.m.
On Thu, 2004-10-21 at 09:28 -0400, Jeff Spaleta wrote:
On Thu, 21 Oct 2004 12:02:13 +0200, Nils Philippsen
<nphilipp(a)redhat.com> wrote:
> Although you don't necessarily need a graphical login.
I'm not sure I like using the argument that expects people to use a
console login in which they are unfamiliar to the tools. As more and
The user can then still login on the command line and run startx as
others have pointed out ;-). Seriously, system-config-authentication
could just run authconfig when not running in X.
more wizardy Setting Setting tools get developer to ease the task of
administration on for subsystems, you have to expect less proficiency
at the commandline among admins in the userbase overall. If openldap
authing can be configured without stepping foot into consoleland,
having a way to troubleshoot common configuration failure modes of
openldap without dropping to console would seem appriopriate. The
argument isn't so much about bare minimum 'needs' to get the job done.
The argument is, adminsn especially less experienced admins, are going
to find ways to use the tools they are comfortable with to solve their
defcon 3 problems so it gets solved as quickly as possible.
With that preamble in mind.... is "best practise" with regard to
openldap or other network authing to have at least one locally authed
unprivlegded "operator" as suggested previously in this thread? If so,
are their opportunities in the ui tools in Core to strongly suggest or
strongarm if not require that such a local operator be created?
Good idea.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
2:16 p.m.
Le jeudi 21 octobre 2004 à 09:28 -0400, Jeff Spaleta a écrit :
On Thu, 21 Oct 2004 12:02:13 +0200, Nils Philippsen
<nphilipp(a)redhat.com> wrote:
> Although you don't necessarily need a graphical login.
I'm not sure I like using the argument that expects people to use a
console login in which they are unfamiliar to the tools. As more and
more wizardy Setting Setting tools get developer to ease the task of
administration on for subsystems, you have to expect less proficiency
at the commandline among admins in the userbase overall. If openldap
authing can be configured without stepping foot into consoleland,
having a way to troubleshoot common configuration failure modes of
openldap without dropping to console would seem appriopriate.
However X can cash too (esp if fixed is served via remote xfs and the
betworking is dead). All too often the developer of the latest gfx admin
gimick forgets to bring the curses interface to parity, which is a majot
PITA when X fails (or remote X fails; etc)
Regards,
--
Nicolas Mailhot
9:51 a.m.
On Thu, 2004-10-21 at 05:53 -0400, Alan Cox wrote:
On Mon, Oct 18, 2004 at 08:27:18PM -0400, Havoc Pennington wrote:
> I agree with you, fwiw. Any reason to need to log in as root is a bug.
Then gdm is a bug 8) You need root login when things like ldap go away otherwise
you can't login.
A lot of sites using LDAP probably also use NFS (or otherwise networked)
home directories, and so if you can't contact the LDAP server, you're
unlikely to be able to get to the NFS server either, and thus you don't
have any access to your data. So what use is it to log in as root?
Besides, giving one's users root access to their machines to make up for
one's inability to set up a reliable, replicated LDAP setup is probably
a bad idea :)
Now, if you're talking about something like laptops: John Dennis and
Dan Reed were working a while back on fixing this. The idea is that the
first time you log in, your credentials are cached. If the network is
unreachable, then your login is verified against cached credentials.
When you can fix gdm to automatically switch to telepathy mode
let me know. Similarly if the system develops problems and you need to boot
to single user you need root.
That doesn't really count as "login". I don't think anyone was
suggesting to disable single user mode out of the box.
9:58 a.m.
On Thu, 2004-10-21 at 10:51 -0400, Colin Walters wrote:
On Thu, 2004-10-21 at 05:53 -0400, Alan Cox wrote:
> On Mon, Oct 18, 2004 at 08:27:18PM -0400, Havoc Pennington wrote:
> > I agree with you, fwiw. Any reason to need to log in as root is a bug.
>
> Then gdm is a bug 8) You need root login when things like ldap go away otherwise
> you can't login.
A lot of sites using LDAP probably also use NFS (or otherwise networked)
home directories, and so if you can't contact the LDAP server, you're
unlikely to be able to get to the NFS server either, and thus you don't
have any access to your data. So what use is it to log in as root?
Because root can typically login b/c:
root account/pw is local
root homedir is local
root can fix the problem if it's just a futzed network adapter.
-sv
10:15 a.m.
On Thu, 21 Oct 2004, seth vidal wrote:
On Thu, 2004-10-21 at 10:51 -0400, Colin Walters wrote:
> On Thu, 2004-10-21 at 05:53 -0400, Alan Cox wrote:
> > On Mon, Oct 18, 2004 at 08:27:18PM -0400, Havoc Pennington wrote:
> > > I agree with you, fwiw. Any reason to need to log in as root is a bug.
> >
> > Then gdm is a bug 8) You need root login when things like ldap go away
otherwise
> > you can't login.
>
> A lot of sites using LDAP probably also use NFS (or otherwise networked)
> home directories, and so if you can't contact the LDAP server, you're
> unlikely to be able to get to the NFS server either, and thus you don't
> have any access to your data. So what use is it to log in as root?
Because root can typically login b/c:
root account/pw is local
root homedir is local
root can fix the problem if it's just a futzed network adapter.
+1
Tom
10:38 a.m.
On Thu, 2004-10-21 at 11:15 -0400, Tom Diehl wrote:
On Thu, 21 Oct 2004, seth vidal wrote:
> On Thu, 2004-10-21 at 10:51 -0400, Colin Walters wrote:
> > On Thu, 2004-10-21 at 05:53 -0400, Alan Cox wrote:
> > > On Mon, Oct 18, 2004 at 08:27:18PM -0400, Havoc Pennington wrote:
> > > > I agree with you, fwiw. Any reason to need to log in as root is a
bug.
> > >
> > > Then gdm is a bug 8) You need root login when things like ldap go away
otherwise
> > > you can't login.
> >
> > A lot of sites using LDAP probably also use NFS (or otherwise networked)
> > home directories, and so if you can't contact the LDAP server, you're
> > unlikely to be able to get to the NFS server either, and thus you don't
> > have any access to your data. So what use is it to log in as root?
>
> Because root can typically login b/c:
> root account/pw is local
> root homedir is local
> root can fix the problem if it's just a futzed network adapter.
+1
root should just login on the console, then startx and be happy. That'd
be my version of "safe mode" anyway ;-P.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
11:04 a.m.
On Thu, 2004-10-21 at 10:58 -0400, seth vidal wrote:
Because root can typically login b/c:
root account/pw is local
root homedir is local
Yes, I understand why root can log in in this scenario, on a technical
level. I'm questioning its usefulness.
root can fix the problem if it's just a futzed network adapter.
You expect normal users in an LDAP setup to be able to debug their
network adapter? And for sysadmins to want to give them the root
password just for this scenario in the first place?
12:32 p.m.
Yes, I understand why root can log in in this scenario, on a
technical
level. I'm questioning its usefulness.
You're questioning the usefulness of root logging in from the console?
If I go to a users machine that has hosed up b/c something went stupid
with a network driver, I'd like to be able to login. drop the device,
bring it back up and not have to reboot the machine.
You expect normal users in an LDAP setup to be able to debug their
network adapter? And for sysadmins to want to give them the root
password just for this scenario in the first place?
I was arguing against what I _thought_ I read, which was getting rid of
ALL root logins. Including tty.
-sv
1:02 p.m.
On Thu, 21 Oct 2004, Colin Walters wrote:
On Thu, 2004-10-21 at 13:32 -0400, seth vidal wrote:
> I was arguing against what I _thought_ I read, which was getting rid of
> ALL root logins. Including tty.
No no, just gdm basically.
I had the same impression as Seth. I do not care about gdm. What I
care about is being able to login as root on any machine ldap is for whatever
reason unavailable. Last time I tried it was not possible to login at all
if ldap is not available. Granted I have not tried in a while and maybe
this is fixed but it used to be a problem.
Regards,
Tom
2:13 p.m.
On Thu, Oct 21, 2004 at 02:02:25PM -0400, Tom Diehl wrote:
I had the same impression as Seth. I do not care about gdm. What I
care about is being able to login as root on any machine ldap is for whatever
reason unavailable. Last time I tried it was not possible to login at all
if ldap is not available. Granted I have not tried in a while and maybe
this is fixed but it used to be a problem.
It's fixed (or at least, worked-around) for for UIDs < 100.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
2:10 p.m.
Le jeudi 21 octobre 2004 à 10:51 -0400, Colin Walters a écrit :
A lot of sites using LDAP probably also use NFS (or otherwise
networked)
home directories, and so if you can't contact the LDAP server, you're
unlikely to be able to get to the NFS server either, and thus you don't
have any access to your data. So what use is it to log in as root?
Fix your nfs/ldap conf and put the system back online.
If ldap/nfs is dead it's not always a problem server-side
(esp. with rawhide clients;)
Though those steps should definitely not require X-with-root
Cheers,
--
Nicolas Mailhot
6:02 p.m.
Warren Togami wrote:
This has NEVER worked for root. It has something to do with
xscreensaver not being very secure.
By which you meant, of course, "xscreensaver is behaving securely by
refusing to allow you to do something that is inherently insecure."
In any case you shouldn't be logging in as root anyway. You
should
use su or sudo when you need root functions.
Yes.
Paul Ionescu wrote:
Well, I know that, but it works fine in KDE.
Then feel free to use KDE. Just because they made a bad decision
does not mean that xscreensaver will ape it.
--
Jamie Zawinski
jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
6:27 p.m.
Then, I think that "lock screen" and "xscreensaver" should not appear
in
menu for root if they don't work as root.
What is the point to have them in the menu (for root of course), if they
don't work ?
On Sun, 17 Oct 2004 16:02:42 -0700, Jamie Zawinski wrote:
Warren Togami wrote:
>
> This has NEVER worked for root. It has something to do with
> xscreensaver not being very secure.
By which you meant, of course, "xscreensaver is behaving securely by
refusing to allow you to do something that is inherently insecure."
> In any case you shouldn't be logging in as root anyway. You should use
> su or sudo when you need root functions.
Yes.
Paul Ionescu wrote:
>
> Well, I know that, but it works fine in KDE.
Then feel free to use KDE. Just because they made a bad decision does
not mean that xscreensaver will ape it.
6:33 p.m.
On Sun, Oct 17, 2004 at 04:02:42PM -0700, Jamie Zawinski wrote:
Warren Togami wrote:
>
> This has NEVER worked for root. It has something to do with
> xscreensaver not being very secure.
By which you meant, of course, "xscreensaver is behaving securely by
refusing to allow you to do something that is inherently insecure."
Hm? xscreensaver drops privileges if runned as root, and thus it won't
be able to access the X cookies file. Ending up unable to connect to the
X server.
It's not a case of it refusing to do something insecure. In fact, in its
documentation, it states that it's "safe to run xscreensaver as root".
But in order for it to work, it asks for a "xhost +localhost".
And that I don't find very secure.
Regards,
Luciano Rocha
--
Consciousness: that annoying time between naps.
6:56 p.m.
Luciano Miguel Ferreira Rocha wrote:
Hm? xscreensaver drops privileges if runned as root, and thus it won't
be able to access the X cookies file. Ending up unable to connect to the
X server.
You'd rather it did what KDE does and not drop privs at all, running
arbitrary eye-candy sub-processes as root?
It's not a case of it refusing to do something insecure. In fact,
in its
documentation, it states that it's "safe to run xscreensaver as root".
But in order for it to work, it asks for a "xhost +localhost".
And that I don't find very secure.
It simply follows the security measures in use by the X server. If you
find those onerous and choose to turn them off, that's your business,
but xscreensaver doesn't do that for you. You could always jump through
hoops like this instead:
xauth -f /home/$USER/.Xauthority nextract - $DISPLAY | xauth nmerge -
--
Jamie Zawinski
jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
7:04 p.m.
On Sun, Oct 17, 2004 at 04:56:12PM -0700, Jamie Zawinski wrote:
Luciano Miguel Ferreira Rocha wrote:
>
> Hm? xscreensaver drops privileges if runned as root, and thus it won't
> be able to access the X cookies file. Ending up unable to connect to the
> X server.
You'd rather it did what KDE does and not drop privs at all, running
arbitrary eye-candy sub-processes as root?
They can't be trusted to run as root? Can they be trusted to be run as
any user at all?
> It's not a case of it refusing to do something insecure. In fact, in its
> documentation, it states that it's "safe to run xscreensaver as
root".
> But in order for it to work, it asks for a "xhost +localhost".
>
> And that I don't find very secure.
It simply follows the security measures in use by the X server. If you
find those onerous and choose to turn them off, that's your business,
No, I find the documentation dangerous.
but xscreensaver doesn't do that for you. You could always jump
through
hoops like this instead:
xauth -f /home/$USER/.Xauthority nextract - $DISPLAY | xauth nmerge -
Why can't xscreensaver do that when run as root? If it sandboxes it
self when it thinks it a necessity, then it should at least do it
properly and fully.
Regards,
Luciano Rocha
--
Consciousness: that annoying time between naps.
7:26 p.m.
Luciano Miguel Ferreira Rocha wrote:
No, I find the documentation dangerous.
Feel free to send me better words then.
Why can't xscreensaver do that when run as root?
Because the right answer is "don't log in as root." I'd rather not
waste my time making it *even easier* for people to have bad security
hygiene.
If it sandboxes it self when it thinks it a necessity, then it
should
at least do it properly and fully.
In my estimation, it already does so. If you'd like it to do more, send
me a patch.
--
Jamie Zawinski
jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
3:42 a.m.
Related to this "don't login into X as root" discussion...
On SUSE Enterprise, if you do a gui login or startx as root, the wall
paper is red with warning symbols and bomb icons. :)
Dax
7:37 a.m.
And the lock screen + xscreensaver works too AFAIK.
On Mon, 18 Oct 2004 02:42:37 -0600, Dax Kelson wrote:
Related to this "don't login into X as root"
discussion...
On SUSE Enterprise, if you do a gui login or startx as root, the wall
paper is red with warning symbols and bomb icons. :)
Dax
4:23 p.m.
On Mon, Oct 18, 2004 at 01:04:53AM +0100, Luciano Miguel Ferreira Rocha wrote:
> You'd rather it did what KDE does and not drop privs at all,
running
> arbitrary eye-candy sub-processes as root?
They can't be trusted to run as root? Can they be trusted to be run as
any user at all?
KDE doesn't support setuid usage, nor does gtk+. Its a sensible policy anyway.
5:26 p.m.
On Wed, Oct 20, 2004 at 05:23:47PM -0400, Alan Cox wrote:
On Mon, Oct 18, 2004 at 01:04:53AM +0100, Luciano Miguel Ferreira
Rocha wrote:
> > You'd rather it did what KDE does and not drop privs at all, running
> > arbitrary eye-candy sub-processes as root?
>
> They can't be trusted to run as root? Can they be trusted to be run as
> any user at all?
KDE doesn't support setuid usage, nor does gtk+. Its a sensible policy anyway.
We're not talking about setuid usage. Nobody claims for xscreensaver to
be set suid.
xscreensaver is a normal application that should cause no problems for a
user running it. If it fails that goal for root, or 'may fail', then it
shouldn't be run as a normal user either.
xscreensaver decision to setuid(nobody) when euid == 0 and then require
a xhost + is just broken. I fail to see a situation where to run cute
(tastes may vary) graphical animations as root would be a no-no,
but to run with X unprotected a possibility.
That it's not a good policy, sure. But it's not up to the developer to
enforce the policy it feels best.
IMO, of course.
Regards,
Luciano Rocha
7:57 p.m.
On Mon, Oct 18, 2004 at 01:32:20AM +0300, Paul Ionescu wrote:
I discovered that xscreensaver and lock screen does not work in gnome
if
the current user is "root".
Is this a bug or a "feature" ?
It's the way it's worked forever. I consider the bug to be that you're given
a full GNOME (or KDE) environment when you log in as root.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:16 p.m.
On Mon, Oct 18, 2004 at 01:32:20AM +0300, Paul Ionescu wrote:
And another question, is there an options to change the unlock prompt
from
xscreensaver ? The default one is UGLY, and does not fit in Gnome desktop.
For a while, one or two years ago, xscreensaver shipped in Raw Hide with
some GTK+2 patches that made the prompt dialog look less alien. I don't
know why the patches were reverted.
--
Rudi
7131
days inactive
7140
days old
76 comments
26 participants
participants (26)
-
Alan Cox -
Colin Walters -
Dax Kelson -
Havoc Pennington -
Jamie Zawinski -
Jef Spaleta -
Jeff Pitman -
Jon Savage -
Jonathan Andrews -
Joshua Eichorn -
Kim B. Nielsen -
Kyrre Ness Sjobak -
Luciano Miguel Ferreira Rocha -
Manuel Moreno -
Matthew Miller -
Michael Favia -
Nicolas Mailhot -
Nils Philippsen -
Paul Ionescu -
Ricardo Veguilla -
Rudi Chiarito -
Sean Middleditch -
seth vidal -
Tom Diehl -
Warren Togami -
Xose Vazquez Perez