Lock screen does not work for root in gnome

[Nils Philippsen]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041019/c4f1f4ce/attachment.sig>