Bug 136622

That seems true, locking as root does not work.

Locking as root does not work on purpose, because of this: http://live.gnome.org/GnomeScreensaver_2fFrequentlyAskedQuestions

That is, the same reason xscreensaver did the same.

Yes, it is on purpose locking does not work. That is not the problem and confirmation here is not a solution for the user on the system.

Again, if a user is allowed to log in to the gui as root, only menu options that will function should be shown or at least warnings should be displayed when root
tries to use such options.

The user on the system should not use root at all. So yeah, probably we want to disable things in the GUI for power users that while being power still forget using X with root is dangerous.

So, marking as enhancement

Is it prefered to call this not an enhancement but a bug since it is security related and other warnings are already on the system for functions not working for root users in the gui mode?

Example: Beagle already warns root users the function is realy disabled and closes itselve to make it clear it does not work for root and thus can not be used.

The Gnome Desktop "lock screen" function for root users does not give any warning about security risks, but still blanks the screen. This gives the impression the lock function has to work and also does work. Untill the user finds out the hard way the blanked screen was not locked...

Yeah, maybe we should display that warning dialog. Anna? JP?

Rodrigo, talk to the upstream maintainer and see what he thinks first.

We could add an english only dialog or message (not to bad since root defaults to english even if another language is selected as primary in yast2).

*** Bug 179800 has been marked as a duplicate of this bug. ***

Raising to major while we review this.

Security team, can you weigh in on this?

the arguments why xscreensaver (http://www.jwz.org/xscreensaver/faq.html#root-lock) doesn't work as root sound bogus to me. Using nobody as unprivileged user for this purpose is wrong anyways. xlock works as root btw.
the pam config for screensavers doesn't include pam_rootok.so therefore the behavior to not lock is hardcoded at an unexpected place.

So I'd consider this behavior a bug in the screensaver. Certainly not a major one though. No need to fix this in already released distros.

Wrt false sense of security: *shrug* just move your mouse and you'll see that it didn't lock. Don't log in as root in the first place.

Anyways, the gnome desktop team should consider using the same nice background for the root user as the KDE desktop. It make it pretty obvious that logging in as root is no good idea without actually displaying any annoying warnings.

does kdm do anything when the user authenticates as root? (like showing a message) I guess we could use that background in GNOME also.

No it doesn't show any message. It does not offer root in the user list though so there is nothing that encourages logging in as root at all.

(In reply to comment #10)
> Wrt false sense of security: *shrug* just move your mouse and you'll see that
> it didn't lock. Don't log in as root in the first place.

Security is not only for people who don't make mistakes or just don't have enough knowledge.

> Anyways, the gnome desktop team should consider using the same nice background
> for the root user as the KDE desktop. It make it pretty obvious that logging
> in as root is no good idea without actually displaying any annoying warnings.
> 

The same unexpected place to code security measures as the current design. It is more secure to place a warning in the screensaver behaviour then to create preventive measures outside it on the desktop. It only takes one nice designer to mangle the screensaver security but a lot of greatfull users to disable a warning option if they don't like it.

One thing we could do is to not show the Lock Screen menu item when running as root. We'd need to patch gnome-panel and gnome-main-menu. JP, Anna, should we do that?

*** Bug 187660 has been marked as a duplicate of this bug. ***

(In reply to comment #14)
> One thing we could do is to not show the Lock Screen menu item when running as
> root. We'd need to patch gnome-panel and gnome-main-menu. JP, Anna, should we
> do that?
> 

I sugest to do so since it all starts with this dangerous menu item. Hope JP and Anna find time for a reply on this question.

*** Bug 200820 has been marked as a duplicate of this bug. ***

*** Bug 204100 has been marked as a duplicate of this bug. ***

*** Bug 207341 has been marked as a duplicate of this bug. ***

i dont really know.

customers seem to expect it ... 

so its a pretty bad user experience, dont you think?

*** Bug 217187 has been marked as a duplicate of this bug. ***

Rodrigo, can you talk to William upstream about why this is done?  I think there are a sufficient number of duplicates to warrant doing this if its not 100% correct.

*** Bug 263268 has been marked as a duplicate of this bug. ***

Ok, so this is still an issue in GNOME 2.18... If we can't get any answers from upstream (comment#23), can we create out own patch for it and lock the screen?

Any news?

The FAQ referenced in comment #2 can be found as
	http://live.gnome.org/GnomeScreensaver/FrequentlyAskedQuestions
nowadays.

I hope Rodrigo can find time to answer the question in comment #23 by now.

This is already available in upstream GNOME (2.20) and 10.3, so the "normal" menu bar applet does not show the lock screen option. It is not fixed though on main-menu, which still displays the Lock Screen option for the root user.

Scott, Jimmy?

Changed gnome-main-menu to work the same way that upstream gnome-panel now does - do not show the lock screen option if logged in as root.

submitted to stable

I think this fix is related to my issue. Logout/Exit and Lock screen gone from my SLAB after some SVN update.

This change was very limited and directly applied only to not showing the lock screen option when root.  Probably should enter a separate bug with details on your issue.

My fault.
desktop-file-install with --vendor supplied and %files not updated.