Today's (9/12) rawhide all users = unable to authenticate user!

[Andy Lawrence]

Booting normally to GDM, using normal root login gives me unable to
authenticate user.  If I boot to init3, my user/pass works just fine, then I
can startx.  I attempted passwd and reset my pass with no luck!

Anybody else?  Should I file this under GDM?

-- 
projecthuh.com
All of my bits are free, are yours? Fedoraproject.org

[darrell pfeifer]

2008/9/12 Dr. Diesel <dr.diesel(a)gmail.com&gt;

>  Booting normally to GDM, using normal root login gives me unable to
>  authenticate user.  If I boot to init3, my user/pass works just fine, then I
>  can startx.  I attempted passwd and reset my pass with no luck!
>
>  Anybody else?  Should I file this under GDM?
>  
The gdm changelog says

* Tue Sep 09 2008 Jon McCann <jmccann(a)redhat.com&gt; - 1:2.23.92-2
- Disallow root login

 So it is intentional

darrell

[Andy Lawrence]

2008/9/12 darrell pfeifer <darrellpf(a)gmail.com&gt;

>  2008/9/12 Dr. Diesel <dr.diesel(a)gmail.com&gt;
>
> > Booting normally to GDM, using normal root login gives me unable to
> > authenticate user.  If I boot to init3, my user/pass works just fine, then I
> > can startx.  I attempted passwd and reset my pass with no luck!
> >
> > Anybody else?  Should I file this under GDM?
> >
>
>  The gdm changelog says
>
>  * Tue Sep 09 2008 Jon McCann <jmccann(a)redhat.com&gt; - 1:2.23.92-2
>
>  - Disallow root login
>
>   So it is intentional
>
>  darrell
>  
Wow, maybe a change of output, to something like "Root login disabled"

Interesting property to suddenly change?

Thanks



-- 
projecthuh.com
All of my bits are free, are yours? Fedoraproject.org

Yum broken & PAM-mount broken

[casimiro barreto]

Ok,

# yum update
...
# poweroff
...

Some time later
# yum update
[root@terra casimiro]# yum update
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 229, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 84, in main
    base.getOptionsConfig(args)
  File "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig
    enabled_plugins=self.optparser._splitArg(opts.enableplugins))
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 189, in
_getConfig
    startupconf.pluginconfpath,disabled_plugins,enabled_plugins)
  File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 355, in
doPluginSetup
    plugin_types, confpath, disabled_plugins, enabled_plugins)
  File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 152, in
__init__
    self._importplugins(types)
  File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 195, in
_importplugins
    self._loadplugin(modulefile, types)
  File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 251, in
_loadplugin
    module = imp.load_module(modname, fp, pathname, description)
  File "/usr/lib/yum-plugins/filter-data.py", line 111
    ('committers', 'committer')]
                               ^
SyntaxError: invalid syntax
[root@terra casimiro]#

Yum broken & PAM-mount broken

[Seth Vidal]

On Fri, 2008-09-12 at 23:49 -0300, Casimiro de Almeida Barreto wrote:
>  Ok,
>  
>  # yum update
>  ...
>  # poweroff
>  ...
>  
>  Some time later
>  # yum update
>  [root@terra casimiro]# yum update
>  Traceback (most recent call last):
>    File "/usr/bin/yum", line 29, in <module>
>      yummain.user_main(sys.argv[1:], exit_code=True)
>    File "/usr/share/yum-cli/yummain.py", line 229, in user_main
>      errcode = main(args)
>    File "/usr/share/yum-cli/yummain.py", line 84, in main
>      base.getOptionsConfig(args)
>    File "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig
>      enabled_plugins=self.optparser._splitArg(opts.enableplugins))
>    File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 189, in
>  _getConfig
>      startupconf.pluginconfpath,disabled_plugins,enabled_plugins)
>    File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 355, in
>  doPluginSetup
>      plugin_types, confpath, disabled_plugins, enabled_plugins)
>    File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 152, in
>  __init__
>      self._importplugins(types)
>    File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 195, in
>  _importplugins
>      self._loadplugin(modulefile, types)
>    File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 251, in
>  _loadplugin
>      module = imp.load_module(modname, fp, pathname, description)
>    File "/usr/lib/yum-plugins/filter-data.py", line 111
>      ('committers', 'committer')]
>                                 ^
>  SyntaxError: invalid syntax
>  [root@terra casimiro]# 
The yum bug:
https://bugzilla.redhat.com/show_bug.cgi?id=460963

-sv

Yum broken & PAM-mount broken

[Till Maas]

On Sat September 13 2008, Casimiro de Almeida Barreto wrote:
[nothing about pam_mount]

Regarding the subject, what is in which version of pam_mount for you broken? 
And please create a bug report for this, if it is not fixed in pam_mount 
0.48.

Regards,
Till

Yum broken & PAM-mount broken

[casimiro barreto]

Till Maas escreveu:
>  On Sat September 13 2008, Casimiro de Almeida Barreto wrote:
>  [nothing about pam_mount]
>
>  Regarding the subject, what is in which version of pam_mount for you broken? 
>  And please create a bug report for this, if it is not fixed in pam_mount 
>  0.48.
>
>  Regards,
>  Till
>     
I'll fill bugzilla. Anyways the "official pam_mount" for fc9 is
0.47 as
shown:

[root@terra casimiro]# rpm -e --allmatches pam_mount
aviso: /etc/security/pam_mount.conf.xml salvo como
/etc/security/pam_mount.conf.xml.rpmsave
[root@terra casimiro]# yum install pam_mount
Plugins carregados: aliases, allowdowngrade, changelog, downloadonly,
                  : fastestmirror, fedorakmod, kernel-module, keys,
list-data,
                  : merge-conf, priorities, protect-packages, protectbase,
                  : refresh-packagekit, refresh-updatesd, tmprepo, tsflags,
                  : upgrade-helper, verify, versionlock
Loading mirror speeds from cached hostfile
 * livna: rpm.livna.org
 * fedora: fedora.c3sl.ufpr.br
 * updates-newkey: mirror.cc.vt.edu
 * updates: ftp.linux.ncsu.edu
Reading version lock configuration
0 packages excluded due to repository protections
Configurando o Processo de Instalação
Analisando argumentos da instalação de pacotes
Resolvendo Dependências
--> Executando verificação da transação
---> Pacote pam_mount.i386 0:0.47-1.fc9 definido para ser atualizado
--> Resolução de Dependências Finalizada

Dependências Resolvidas

================================================================================
 Pacote            Arq.         Versão            
Repositório            Tamanho
================================================================================
Instalando:
 pam_mount         i386         0.47-1.fc9        
updates-newkey         119 k

Transaction Summary
================================================================================
Install      1 Package(s)        
Update       0 Package(s)        
Remove       0 Package(s)        

Tamanho total do download: 119 k
Correto? [s/N]:s
Baixando Pacotes:
pam_mount-0.47-1.fc9.i386.rpm                            | 119 kB    
00:01    
Executando o rpm_check_debug
Executando Teste de Transação
Teste de Transação Finalizado
Teste de Transação Completo
Executando a Transação
  Instalando     : pam_mount                                         [1/1]

Instalados: pam_mount.i386 *0:0.47-1.fc9*
Concluído!

Yum broken & PAM-mount broken

[Till Maas]

On Sat September 13 2008, Casimiro de Almeida Barreto wrote:
>  Till Maas escreveu:
>  > On Sat September 13 2008, Casimiro de Almeida Barreto wrote:
>  > [nothing about pam_mount]
>  >
>  > Regarding the subject, what is in which version of pam_mount for you
>  > broken? And please create a bug report for this, if it is not fixed in
>  > pam_mount 0.48. 
>  I'll fill bugzilla. Anyways the "official pam_mount"
> for fc9 is 0.47 as
>  shown: 
With the next push, pam_mount should be updated to 0.48 in Fedora 8 and 9:
https://admin.fedoraproject.org/updates/pam_mount-0.48-2.fc9,libHX-1.25-1...

Regards,
Till

Yum broken & PAM-mount broken

[casimiro barreto]

Till Maas escreveu:
>  On Sat September 13 2008, Casimiro de Almeida Barreto wrote:
>    
> > Till Maas escreveu:
> >     
> >> On Sat September 13 2008, Casimiro de Almeida Barreto wrote:
> >> [nothing about pam_mount]
> >>
> >> Regarding the subject, what is in which version of pam_mount for you
> >> broken? And please create a bug report for this, if it is not fixed in
> >> pam_mount 0.48.
> >>       
>
>    
> > I'll fill bugzilla. Anyways the "official pam_mount" for fc9 is 0.47
> as
> > shown:
> >     
>
>  With the next push, pam_mount should be updated to 0.48 in Fedora 8 and 9:
>  https://admin.fedoraproject.org/updates/pam_mount-0.48-2.fc9,libHX-1.25-1...
>
>  Regards,
>  Till
>     
Ok,

I'm transcripting the debugging information. First of all I have an
encripted "partition" for /home/casimiro that is mount via loop0. It was
working well until last update. It is still mounting when I use input lile:

# openssl aes-256-cbc -d -in /etc/pki/cryptofs/mykey.key | mount -p0 -o
loop,encryption=aes-cbc-256,rw /xxx/yyy.img /home/casimiro

But, when it goes to PAM... that's what happen:

Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:259)
pam_mount 0.47: entering auth stage
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:269) could
not get password from PAM system
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:191) enter
read_password
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:294) saving
authtok for session code (authtok=0x8e0d630)
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:437)
pam_mount 0.47: entering session stage
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:458) back
from global readconfig
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:460) per-user
configurations not allowed by pam_mount.conf.xml
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(misc.c:45) Session open:
(uid=0, euid=0, gid=501, egid=501)
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(rdconf2.c:190) checking
sanity of volume record (/home/.casimiro.img)
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:512) about to
perform mount operations
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:364) information
for mount:
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:365)
----------------------
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:366) (defined by
globalconf)
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:367)
user:          casimiro
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:368)
server:        (null)
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:369)
volume:        /xxx/yyy.img
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:370)
mountpoint:    /home/casimiro
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:371)
options:       loop,encryption=aes-cbc-256,rw
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:372)
fs_key_cipher: aes-256-cbc
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:373)
fs_key_path:   /etc/pki/cryptofs/mykey.key
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:374) use_fstab:     0
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:375)
----------------------
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:151) realpath of
volume "/home/casimiro" is "/home/casimiro"
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:155) checking to
see if /xxx/yyy.img is already mounted at /home/casimiro
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:824) checking for
encrypted filesystem key configuration
Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:831) decrypting
FS key using system auth. token and aes-256-cbc
Sep 13 12:14:28 terra kdm[3019]: Unknown session exit code 0 (sig 6)
from manager process
Sep 13 12:14:28 terra kdm_greet[3072]: Cannot read from core
Sep 13 12:14:39 terra login: pam_mount(pam_mount.c:259) pam_mount 0.47:
entering auth stage
Sep 13 12:14:39 terra login: pam_mount(pam_mount.c:269) could not get
password from PAM system
Sep 13 12:14:39 terra login: pam_mount(pam_mount.c:191) enter read_password
Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:294) saving authtok
for session code (authtok=0x94f04d8)
Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:437) pam_mount 0.47:
entering session stage
Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:458) back from global
readconfig
Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:460) per-user
configurations not allowed by pam_mount.conf.xml
Sep 13 12:14:42 terra login: pam_mount(misc.c:45) Session open: (uid=0,
euid=0, gid=0, egid=0)
Sep 13 12:14:42 terra login: pam_mount(rdconf2.c:190) checking sanity of
volume record (/xxx/yyy.img)
Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:512) about to perform
mount operations
Sep 13 12:14:42 terra login: pam_mount(mount.c:364) information for mount:
Sep 13 12:14:42 terra login: pam_mount(mount.c:365) ----------------------
Sep 13 12:14:42 terra login: pam_mount(mount.c:366) (defined by globalconf)
Sep 13 12:14:42 terra login: pam_mount(mount.c:367) user:          casimiro
Sep 13 12:14:42 terra login: pam_mount(mount.c:368) server:        (null)
Sep 13 12:14:42 terra login: pam_mount(mount.c:369) volume:       
/xxx/yyy.img
Sep 13 12:14:42 terra login: pam_mount(mount.c:370) mountpoint:   
/home/casimiro
Sep 13 12:14:42 terra login: pam_mount(mount.c:371) options:      
loop,encryption=aes-cbc-256,rw
Sep 13 12:14:42 terra login: pam_mount(mount.c:372) fs_key_cipher:
aes-256-cbc
Sep 13 12:14:42 terra login: pam_mount(mount.c:373) fs_key_path:  
/etc/pki/cryptofs/mykey.key
Sep 13 12:14:42 terra login: pam_mount(mount.c:374) use_fstab:     0
Sep 13 12:14:42 terra login: pam_mount(mount.c:375) ----------------------
Sep 13 12:14:42 terra login: pam_mount(mount.c:151) realpath of volume
"/home/casimiro" is "/home/casimiro"
Sep 13 12:14:42 terra login: pam_mount(mount.c:155) checking to see if
/xxx/yyy.img is already mounted at /home/casimiro
Sep 13 12:14:42 terra login: pam_mount(mount.c:824) checking for
encrypted filesystem key configuration
Sep 13 12:14:42 terra login: pam_mount(mount.c:831) decrypting FS key
using system auth. token and aes-256-cbc
Sep 13 12:14:42 terra init: tty1 main process (3034) killed by ABRT signal
Sep 13 12:14:42 terra init: tty1 main process ended, respawning

And them, back to /etc/security/pam_mount.conf.xml:

<?xml version="1.0" encoding="UTF-8"?>
<pam_mount>

<debug enable="1" />

<mkmountpoint enable="1" />

<fsckloop device="/dev/loop7" />

<mntoptions allow="nosuid,nodev,loop,encryption,fsck" />

<mntoptions require="nosuid,nodev" />

<lsof>/usr/sbin/lsof %(MNTPT)</lsof>

<fsck>/sbin/fsck -p %(FSCKTARGET)</fsck>

<losetup>/sbin/losetup -p0 "%(before=\"-e\" CIPHER)"
"%(before=\"-k\"
KEYBITS)" %(FSCKLOOP) %(VOLUME)</losetup>

<unlosetup>/sbin/losetup -d %(FSCKLOOP)</unlosetup>

<cifsmount>/bin/mount -t cifs //%(SERVER)/%(VOLUME) %(MNTPT) -o
"user=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\"
OPTIONS)"</cifsmount>

<smbmount>/usr/bin/smbmount //%(SERVER)/%(VOLUME) %(MNTPT) -o
"username=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\"
OPTIONS)"</smbmount>

<ncpmount>/usr/bin/ncpmount %(SERVER)/%(USER) %(MNTPT) -o
"pass-fd=0,volume=%(VOLUME)%(before=\",\" OPTIONS)"</ncpmount>

<smbumount>/usr/bin/smbumount %(MNTPT)</smbumount>

<ncpumount>/usr/bin/ncpumount %(MNTPT)</ncpumount>

<fusemount>/sbin/mount.fuse %(VOLUME) %(MNTPT) "%(before=\"-o\"
OPTIONS)"</fusemount>

<fuseumount>/usr/bin/fusermount -u %(MNTPT)</fuseumount>

<umount>/bin/umount %(MNTPT)</umount>

<lclmount>/bin/mount -p0 -t %(FSTYPE) %(VOLUME) %(MNTPT)
"%(before=\"-o\" OPTIONS)"</lclmount>

<cryptmount>/bin/mount -t crypt "%(before=\"-o\" OPTIONS)"
%(VOLUME)
%(MNTPT)</cryptmount>

<nfsmount>/bin/mount %(SERVER):%(VOLUME) %(MNTPT) "%(before=\"-o\"
OPTIONS)"</nfsmount>



<mntcheck>/bin/mount</mntcheck>

<pmvarrun>/usr/sbin/pmvarrun -u %(USER) -o %(OPERATION)</pmvarrun>

<volume fskeycipher="aes-256-cbc"
options="loop,encryption=aes-cbc-256,rw"
fskeypath="/etc/pki/cryptofs/mykey.key" user="casimiro"
mountpoint="/home/casimiro" path="/xxx/yyy.img"
fstype="ext3" />

<volume fskeycipher="aes-256-cbc"
options="loop,encryption=aes-cbc-256,rw"
fskeypath="/media/disk/.developer.key" user="developer"
mountpoint="/home/developer" path="/media/disk/.developer.img"
fstype="ext3" />

</pam_mount>


note that developer is in a flash memory...

Yum broken & PAM-mount broken

[Till Maas]

On Sat September 13 2008, Casimiro de Almeida Barreto wrote:

>  I'm transcripting the debugging information. First of all I have
> an
>  encripted "partition" for /home/casimiro that is mount via loop0. It was
>  working well until last update. It is still mounting when I use input lile:
>
>  # openssl aes-256-cbc -d -in /etc/pki/cryptofs/mykey.key | mount -p0 -o
>  loop,encryption=aes-cbc-256,rw /xxx/yyy.img /home/casimiro 
There is a bug fixed in pam_mount 0.48 that fixes a bug that is triggered in 
your setup.

If you have a FAS account and a client certificate in the .fedora.cert file 
and the Fedora server ca cert in the .fedora-server-ca.cert file, then you 
can already securly download the rpm for i386 with the following command:
 
wget --ca-certificate=.fedora-server-ca.cert --certificate .fedora.cert --private-key
.fedora.cert -O 
pam_mount-0.48-2.fc9.i386.rpm
"https://koji.fedoraproject.org/koji/getfile?taskID=824307&name=pam_mount-0.48-2.fc9.i386.rpm"

Regards,
Till

[Matthew Woehlke]

darrell pfeifer wrote:
>  2008/9/12 Dr. Diesel <dr.diesel(a)gmail.com&gt;
>  
> > Booting normally to GDM, using normal root login gives me unable to
> > authenticate user.  If I boot to init3, my user/pass works just fine, then I
> > can startx.  I attempted passwd and reset my pass with no luck!
> >
> > Anybody else?  Should I file this under GDM?
> >
>  
>  The gdm changelog says
>  
>  * Tue Sep 09 2008 Jon McCann <jmccann(a)redhat.com&gt; - 1:2.23.92-2
>  - Disallow root login
>  
>   So it is intentional 
So... what exactly are we supposed to do when the user login gets hosed? 
Reach for a rescue disk? (Seriously, what's with the sudden trend to 
make fixing problems harder by making recovery modes inaccessible in an 
apparent bid to hide the "confusing/potentially dangerous" bits of the 
system from the user?)

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet

[Nigel Jones]

On Fri, 2008-09-12 at 23:35 -0500, Matthew Woehlke wrote:
>  darrell pfeifer wrote:
>  > 2008/9/12 Dr. Diesel <dr.diesel(a)gmail.com&gt;
>  > 
>  >> Booting normally to GDM, using normal root login gives me unable to
>  >> authenticate user.  If I boot to init3, my user/pass works just fine, then I
>  >> can startx.  I attempted passwd and reset my pass with no luck!
>  >>
>  >> Anybody else?  Should I file this under GDM?
>  >>
>  > 
>  > The gdm changelog says
>  > 
>  > * Tue Sep 09 2008 Jon McCann <jmccann(a)redhat.com&gt; - 1:2.23.92-2
>  > - Disallow root login
>  > 
>  >  So it is intentional
>  
>  So... what exactly are we supposed to do when the user login gets hosed? 
>  Reach for a rescue disk? (Seriously, what's with the sudden trend to 
>  make fixing problems harder by making recovery modes inaccessible in an 
>  apparent bid to hide the "confusing/potentially dangerous" bits of the 
>  system from the user?)
> From memory GDM has always done this, (I personally don't use GDM, I 
favour
KDM), I remember some FC5 machines in particular that required a
GDM configuration hack to allow root logins.

Overall, I'm in favour of not allowing root GUI logins by default, I'd
imagine we are still going to always have direct root CLI logins.

What I'd like to see, is sudo being setup by default (full access w/
password) for the first user (as configured during firstboot).
>  
>  -- 
>  Matthew
>  ENOWIT: .sig file for this machine not set up yet
>   
-- 
Nigel Jones <dev(a)nigelj.com&gt;

[Steven Moix]

On Sat, 2008-09-13 at 17:53 +1200, Nigel Jones wrote:

>  Overall, I'm in favour of not allowing root GUI logins by
> default, I'd
>  imagine we are still going to always have direct root CLI logins. 
Really, I think this is a very bad idea. The root user isn't shown in
the login GUI anyways, so if someone types "root" by hand, he really
wants to be root.

I don't see the point of going the Ubuntu "protect us from ourselves"
way.

Steven

[Martin Sourada]

>  What I'd like to see, is sudo being setup by default (full access
> w/
>  password) for the first user (as configured during firstboot). 
Please no! Sudo is not the good way to do this kind of things. There is
PolicyKit for doing such things correctly.

Martin

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Thorsten Leemhuis]

On 13.09.2008 12:16, Martin Sourada wrote:
> > What I'd like to see, is sudo being setup by default (full
> access w/
> > password) for the first user (as configured during firstboot). 
I'm not sure if that's a good idea, as that could lead to unwilling 
side-effect as that's easily forgotten by those not familiar with this 
behavior in Fedora.

But a checkbox with a text "User is the sysadmin for this system" might 
makes sense in firstboot -- that checkbox could not only configure sudo 
and/or PolicyKit access but also do other things like setting up a alias 
to /etc/aliases to make sure the user in question retrieves the mail 
send to root.

>  Please no! Sudo is not the good way to do this kind of things. There
> is
>  PolicyKit for doing such things correctly. 
Then please tell me how for example read /var/log/messages or other log 
files from /var/log/ using PolicyKit from a {gnome,kde}-terminal(¹) with 
an easy to remember and fast to type command (like "sudo"). tia -- I'm 
really curious if such a command exists.

CU
knurd

(¹) something most of us have done in the past or regularly do

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Matthew Miller]

On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote:
>  But a checkbox with a text "User is the sysadmin for this
> system" might 
>  makes sense in firstboot -- that checkbox could not only configure sudo 
>  and/or PolicyKit access but also do other things like setting up a alias to 
>  /etc/aliases to make sure the user in question retrieves the mail send to 
>  root. 
If we do this (and I'm for it), we should make this work by uncommenting the
wheel group in /etc/sudoers, and having said checkbox add the user to the
wheel group.


-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Seth Vidal]

On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote:
>  On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote:
>  > But a checkbox with a text "User is the sysadmin for this system" might 
>  > makes sense in firstboot -- that checkbox could not only configure sudo 
>  > and/or PolicyKit access but also do other things like setting up a alias to 
>  > /etc/aliases to make sure the user in question retrieves the mail send to 
>  > root.
>  
>  If we do this (and I'm for it), we should make this work by uncommenting the
>  wheel group in /etc/sudoers, and having said checkbox add the user to the
>  wheel group. 
I don't like the wheel group way into sudoers. Not the least of which
because the wheel group, on systems which are using some other form of
nss than local files, can be mucked with too easily.

-sv

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Stephen John Smoogen]

On Sat, Sep 13, 2008 at 6:58 AM, Seth Vidal <skvidal(a)fedoraproject.org&gt; wrote:
>  On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote:
> > On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote:
> > > But a checkbox with a text "User is the sysadmin for this system"
> might
> > > makes sense in firstboot -- that checkbox could not only configure sudo
> > > and/or PolicyKit access but also do other things like setting up a alias to
> > > /etc/aliases to make sure the user in question retrieves the mail send to
> > > root.
> >
> > If we do this (and I'm for it), we should make this work by uncommenting the
> > wheel group in /etc/sudoers, and having said checkbox add the user to the
> > wheel group.
>
>  I don't like the wheel group way into sudoers. Not the least of which
>  because the wheel group, on systems which are using some other form of
>  nss than local files, can be mucked with too easily.
>  
Any solution is going to be fragile in the case of a network'd
computer. Unix permission scheme was never designed with that in mind.
So
what is the 80% use solution? Of the fedora users, are 80% covered by
local files or using nss_XXX? I am not for wheel or against it.. I
just figure we should look at what is the majority use scheme and work
around it for the rest.

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Seth Vidal]

On Sun, 2008-09-14 at 13:26 -0600, Stephen John Smoogen wrote:
>  On Sat, Sep 13, 2008 at 6:58 AM, Seth Vidal
> <skvidal(a)fedoraproject.org&gt; wrote:
>  > On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote:
>  >> On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote:
>  >> > But a checkbox with a text "User is the sysadmin for this system"
> might
>  >> > makes sense in firstboot -- that checkbox could not only configure sudo
>  >> > and/or PolicyKit access but also do other things like setting up a alias
> to
>  >> > /etc/aliases to make sure the user in question retrieves the mail send to
>  >> > root.
>  >>
>  >> If we do this (and I'm for it), we should make this work by uncommenting
> the
>  >> wheel group in /etc/sudoers, and having said checkbox add the user to the
>  >> wheel group.
>  >
>  > I don't like the wheel group way into sudoers. Not the least of which
>  > because the wheel group, on systems which are using some other form of
>  > nss than local files, can be mucked with too easily.
>  >
>  
>  Any solution is going to be fragile in the case of a network'd
>  computer. Unix permission scheme was never designed with that in mind.
>  So
>  what is the 80% use solution? Of the fedora users, are 80% covered by
>  local files or using nss_XXX? I am not for wheel or against it.. I
>  just figure we should look at what is the majority use scheme and work
>  around it for the rest.
>   
80% is the entry gets added to /etc/sudoers by the user addition
interface if 'make this user an admin' is checked.

I think the entry would look like:

username ALL=(ALL)    ALL

-sv

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Nigel Jones]

On Sun, 2008-09-14 at 17:09 -0400, Seth Vidal wrote:
>  On Sun, 2008-09-14 at 13:26 -0600, Stephen John Smoogen wrote:
>  > On Sat, Sep 13, 2008 at 6:58 AM, Seth Vidal <skvidal(a)fedoraproject.org&gt;
> wrote:
>  > > On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote:
>  > >> On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote:
>  > >> > But a checkbox with a text "User is the sysadmin for this
> system" might
>  > >> > makes sense in firstboot -- that checkbox could not only configure
> sudo
>  > >> > and/or PolicyKit access but also do other things like setting up a
> alias to
>  > >> > /etc/aliases to make sure the user in question retrieves the mail send
> to
>  > >> > root.
>  > >>
>  > >> If we do this (and I'm for it), we should make this work by
> uncommenting the
>  > >> wheel group in /etc/sudoers, and having said checkbox add the user to the
>  > >> wheel group.
>  > >
>  > > I don't like the wheel group way into sudoers. Not the least of which
>  > > because the wheel group, on systems which are using some other form of
>  > > nss than local files, can be mucked with too easily.
>  > >
>  > 
>  > Any solution is going to be fragile in the case of a network'd
>  > computer. Unix permission scheme was never designed with that in mind.
>  > So
>  > what is the 80% use solution? Of the fedora users, are 80% covered by
>  > local files or using nss_XXX? I am not for wheel or against it.. I
>  > just figure we should look at what is the majority use scheme and work
>  > around it for the rest.
>  > 
>  
>  80% is the entry gets added to /etc/sudoers by the user addition
>  interface if 'make this user an admin' is checked.
>  
>  I think the entry would look like:
>  
>  username ALL=(ALL)     
I agree, I've filed an RFE as bug #462161
(https://bugzilla.redhat.com/show_bug.cgi?id=462161), forgot to mention
it previously.

- Nigel
>  
>  -sv
>  
>  
>   
-- 
Nigel Jones <dev(a)nigelj.com&gt;

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Stephen John Smoogen]

On Sun, Sep 14, 2008 at 3:09 PM, Seth Vidal <skvidal(a)fedoraproject.org&gt; wrote:
>  On Sun, 2008-09-14 at 13:26 -0600, Stephen John Smoogen wrote:
> > On Sat, Sep 13, 2008 at 6:58 AM, Seth Vidal <skvidal(a)fedoraproject.org&gt; wrote:
> > > On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote:
> > >> On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote:
> > >> > But a checkbox with a text "User is the sysadmin for this
> system" might
> > >> > makes sense in firstboot -- that checkbox could not only configure
> sudo
> > >> > and/or PolicyKit access but also do other things like setting up a
> alias to
> > >> > /etc/aliases to make sure the user in question retrieves the mail send
> to
> > >> > root.
> > >>
> > >> If we do this (and I'm for it), we should make this work by uncommenting
> the
> > >> wheel group in /etc/sudoers, and having said checkbox add the user to the
> > >> wheel group.
> > >
> > > I don't like the wheel group way into sudoers. Not the least of which
> > > because the wheel group, on systems which are using some other form of
> > > nss than local files, can be mucked with too easily.
> > >
> >
> > Any solution is going to be fragile in the case of a network'd
> > computer. Unix permission scheme was never designed with that in mind.
> > So
> > what is the 80% use solution? Of the fedora users, are 80% covered by
> > local files or using nss_XXX? I am not for wheel or against it.. I
> > just figure we should look at what is the majority use scheme and work
> > around it for the rest.
> >
>
>  80% is the entry gets added to /etc/sudoers by the user addition
>  interface if 'make this user an admin' is checked.
>
>  I think the entry would look like:
>
>  username ALL=(ALL)    ALL
>  
Perfect for me. Its my first step after logging in... just as long as
we dont do

username ALL=(ALL)    NOPASSWD: ALL
username ALL=(ALL)    ANNOYINGPOPUP: ALL

-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Matthew Miller]

On Sun, Sep 14, 2008 at 05:09:57PM -0400, Seth Vidal wrote:
>  80% is the entry gets added to /etc/sudoers by the user addition
>  interface if 'make this user an admin' is checked.
>  I think the entry would look like:
>  username ALL=(ALL)    ALL 
The problem is that this is file has a ridiculously complicated and picky
syntax. I am really skeptical about machine-editing it. It seems a lot safer
to have a group there, and add and remove from that group. It doesn't have
to be "wheel", although that's traditional.

Plus, we get userhelper auth-as-user functionality basically for free.

-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Jesse Keating]

On Wed, 2008-09-17 at 11:23 -0400, Matthew Miller wrote:
>  The problem is that this is file has a ridiculously complicated and
> picky
>  syntax. I am really skeptical about machine-editing it. 
Augeas ?  /etc/sudoers.d/ ?  It's not like we haven't solved the problem
of 'complicated and picky syntax' before...

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Simo Sorce]

On Wed, 2008-09-17 at 08:47 -0700, Jesse Keating wrote:
>  On Wed, 2008-09-17 at 11:23 -0400, Matthew Miller wrote:
>  > The problem is that this is file has a ridiculously complicated and picky
>  > syntax. I am really skeptical about machine-editing it.
>  
>  Augeas ?  /etc/sudoers.d/ ?  It's not like we haven't solved the problem
>  of 'complicated and picky syntax' before... 
Why preferring to modify the file instead of the simpler method of using
group memeberships ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Jesse Keating]

On Wed, 2008-09-17 at 11:52 -0400, Simo Sorce wrote:
>  > Augeas ?  /etc/sudoers.d/ ?  It's not like we haven't
> solved the problem
>  > of 'complicated and picky syntax' before...
>  
>  Why preferring to modify the file instead of the simpler method of using
>  group memeberships ? 
I don't have a preference, I just didn't buy the argument provided.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

configuring sudo by default

[Thorsten Leemhuis]

On 17.09.2008 17:47, Jesse Keating wrote:
>  On Wed, 2008-09-17 at 11:23 -0400, Matthew Miller wrote:
> > The problem is that this is file has a ridiculously complicated and picky
> > syntax. I am really skeptical about machine-editing it.
>  Augeas ?  
Augeas afaik (correct me if I'm wrong) doesn't solve the "rpmnew files 
get generated and need to be manually merged if local conf file was 
modified"-problem. This

>  /etc/sudoers.d/ ?   
OTOH would.

CU
knurd

configuring sudo by default

[jude ui]

>  On Wed, 2008-09-17 at 11:23 -0400, Matthew Miller wrote:
> >
> >> >The problem is that this is file has a ridiculously complicated and
> >> picky
> >> >syntax. I am really skeptical about machine-editing it.
> >
> > 
What do you mean machine edit it?

configuring sudo by default

[Matthew Miller]

On Thu, Sep 18, 2008 at 08:53:50AM -0400, jude ui wrote:
>  >>> >The problem is that this is file has a ridiculously
> complicated and
>  >>> >picky syntax. I am really skeptical about machine-editing it.
>  What do you mean machine edit it? 
Having a program modify the file; it's not designed for that.

-- 
Matthew Miller <mattdm(a)mattdm.org&gt;
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Matthew Miller]

On Wed, Sep 17, 2008 at 08:47:25AM -0700, Jesse Keating wrote:
>  Augeas ?  /etc/sudoers.d/ ?  It's not like we haven't solved
> the problem
>  of 'complicated and picky syntax' before... 
It could be done, but /etc/sudoers.d still might have odd interactions with
the main file, and in any case it'd be a certain amount of work which might
not get accepted upstream. Meanwhile, group approach works right now and
requires a one character change to an existing config file.

Developing a special sudoers.d directory also doesn't automatically work
with userhelper/consolehelper -- which the group solution does. (And
PolicyKit can work off group membership too, right?)

-- 
Matthew Miller <mattdm(a)mattdm.org&gt;
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Callum Lerwick]

On Wed, 2008-09-17 at 19:35 -0400, Matthew Miller wrote:
>  It could be done, but /etc/sudoers.d still might have odd
> interactions with
>  the main file, and in any case it'd be a certain amount of work which might
>  not get accepted upstream. Meanwhile, group approach works right now and
>  requires a one character change to an existing config file.
>  
>  Developing a special sudoers.d directory also doesn't automatically work
>  with userhelper/consolehelper -- which the group solution does. (And
>  PolicyKit can work off group membership too, right?) 
Also, with a 'chgrp wheel /var/log/messages' and a 'chmod
640 /var/log/messages' you can solve the log reading problem too. Maybe
we should consider making that default too...

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Matthew Miller]

On Wed, Sep 17, 2008 at 09:29:42PM -0500, Callum Lerwick wrote:
>  > Developing a special sudoers.d directory also doesn't
> automatically work
>  > with userhelper/consolehelper -- which the group solution does. (And
>  > PolicyKit can work off group membership too, right?)
>  Also, with a 'chgrp wheel /var/log/messages' and a 'chmod
>  640 /var/log/messages' you can solve the log reading problem too. Maybe
>  we should consider making that default too... 
Heh. Also already the default in BU Linux. :)

-- 
Matthew Miller <mattdm(a)mattdm.org&gt;
Senior Systems Architect 
Cyberinfrastructure Labs
Computing & Information Technology 
Harvard School of Engineering & Applied Sciences

configuring sudo by default

[Jeroen van Meeuwen]

Seth Vidal wrote:
>  On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote:
> > On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote:
> >> But a checkbox with a text "User is the sysadmin for this system" might
>
> >> makes sense in firstboot -- that checkbox could not only configure sudo 
> >> and/or PolicyKit access but also do other things like setting up a alias to 
> >> /etc/aliases to make sure the user in question retrieves the mail send to 
> >> root.
> > If we do this (and I'm for it), we should make this work by uncommenting the
> > wheel group in /etc/sudoers, and having said checkbox add the user to the
> > wheel group.
>  
>  I don't like the wheel group way into sudoers. Not the least of which
>  because the wheel group, on systems which are using some other form of
>  nss than local files, can be mucked with too easily.
>   
I'm not sure I see how this can be mucked with...

If anything other then local files is used by nss the group membership 
of local files is supposed to be overriden, not extended, and the 
group's members from the other form of nss should be used, isn't it? 
This is at least the case for nss_ldap with nsswitch set to 'files ldap' 
(a case I had the chance to verify just now).

Kind regards,

Jeroen van Meeuwen
-kanarip

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Matthew Miller]

On Sat, Sep 13, 2008 at 08:58:46AM -0400, Seth Vidal wrote:
>  I don't like the wheel group way into sudoers. Not the least of
> which
>  because the wheel group, on systems which are using some other form of
>  nss than local files, can be mucked with too easily. 
If you can muck with groups, you can get into the group 'root', and the
point is moot, no?

-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!)

[Martin Sourada]

On Sat, 2008-09-13 at 14:02 +0200, Thorsten Leemhuis wrote:
>  I'm not sure if that's a good idea, as that could lead to
> unwilling 
>  side-effect as that's easily forgotten by those not familiar with this 
>  behavior in Fedora.
>  
>  But a checkbox with a text "User is the sysadmin for this system" might 
>  makes sense in firstboot -- that checkbox could not only configure sudo 
>  and/or PolicyKit access but also do other things like setting up a alias 
>  to /etc/aliases to make sure the user in question retrieves the mail 
>  send to root.
>   
Yeah, that seems to me to make sense. What I am mostly against is having
full access to sudo without password by default by any user. I believe
PolicyKit is designed to solve this issue by granting rights (by admin)
to user to do this and that and not do other admin tasks...

>  > Please no! Sudo is not the good way to do this kind of things.
> There is
>  > PolicyKit for doing such things correctly.
>  
>  Then please tell me how for example read /var/log/messages or other log 
>  files from /var/log/ using PolicyKit from a {gnome,kde}-terminal(¹) with 
>  an easy to remember and fast to type command (like "sudo"). tia -- I'm 
>  really curious if such a command exists.
>   
Good point. I am by no means expert in this area, but from I heard/read,
it seems like PolicyKit is designed to fine-tune such things as well,
though it's probably not implemented currently. Basically the
implementation should IMHO be like cat/nano/vi/whatever detects that you
are trying to access some file you don't have enough rights to access,
then it asks PolicyKit whether to allow it or not and PolicyKit handles
the rest (i.e. checks whether your admin already allowed that access for
you, if not asks for root password for allowing the access and if
succeeded sends back that its OK for you to access the file). Ideally it
wouldn't require any additional command (like sudo). Though probably
this would need to be implemented on filesystem level, rather than in
cat/nano/...

When I want to view logs (though I don't very much understand why I
cannot read them as normal user) I just log in as root (in
console/gnome-terminal only!). Yeah it's not pleasant to write root
password every time I want to do some admin task - and that's probably
one of the reasons why PolicyKit has been developed - but I think
allowing full access to sudo without password for normal user account is
a big security hole.

Anyway my point in short is that I think allowing full sudo access
without password is wrong unless you really know what that means and I
believe PolicyKit was partly developed to avoid the need for that.

>  CU
>  knurd
>   
Martin

>  (¹) something most of us have done in the past or regularly do
>

configuring sudo by default

[Karsten Wade]

On Sat, 2008-09-13 at 14:02 +0200, Thorsten Leemhuis wrote:

>  But a checkbox with a text "User is the sysadmin for this
> system" might 
>  makes sense in firstboot -- that checkbox could not only configure sudo 
>  and/or PolicyKit access but also do other things like setting up a alias 
>  to /etc/aliases to make sure the user in question retrieves the mail 
>  send to root. 
+1

From a documentation perspective, not having 'sudo' setup by default is
a major PITA.  We have these options currently in writing:

a. In each document that requires doing actions as root, have a section
that explains how to configure 'sudo'
  1. Or we have to send them out to a stand-alone Sudo How To, which can
be described as, "sucky reader experience."

b. Use 'su -c' in all situations, despite other Linux tutorials commonly
using sudo
  b.1 Why does this matter?  It's good to follow a common practice to
make readers more familiar and comfortable; tutorials can more easily be
reused or apply to Fedora.
  b.2 Also 'su' requires knowing the root password, where 'sudo'
doesn't.

The situation we have without 'sudo' configured by user-who-is-admin is
that the user must know and use the root password on a regular basis.
Super evil may ensue.  Makes writing documentation exponentially more
difficult.

- Karsten
-- 
Karsten Wade, Community Gardener
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key :

[Matthew Woehlke]

Nigel Jones wrote:
>  On Fri, 2008-09-12 at 23:35 -0500, Matthew Woehlke wrote:
> > darrell pfeifer wrote:
> >> 2008/9/12 Dr. Diesel <dr.diesel(a)gmail.com&gt;
> >>
> >>> Booting normally to GDM, using normal root login gives me unable to
> >>> authenticate user.  If I boot to init3, my user/pass works just fine, then I
> >>> can startx.  I attempted passwd and reset my pass with no luck!
> >>>
> >>> Anybody else?  Should I file this under GDM?
> >>>
> >> The gdm changelog says
> >>
> >> * Tue Sep 09 2008 Jon McCann <jmccann(a)redhat.com&gt; - 1:2.23.92-2
> >> - Disallow root login
> >>
> >>  So it is intentional
> > So... what exactly are we supposed to do when the user login gets hosed? 
> > Reach for a rescue disk? (Seriously, what's with the sudden trend to 
> > make fixing problems harder by making recovery modes inaccessible in an 
> > apparent bid to hide the "confusing/potentially dangerous" bits of the 
> > system from the user?)
>  From memory GDM has always done this, (I personally don't use GDM, I
>  favour KDM), I remember some FC5 machines in particular that required a
>  GDM configuration hack to allow root logins. 
Last I checked I can login as root (in the display manager, which AFAIK 
is gdm) on this box. This is F9, and at any rate I'm 99% sure it worked 
in F8.

>  Overall, I'm in favour of not allowing root GUI logins by
> default, I'd
>  imagine we are still going to always have direct root CLI logins. 
...unless the "let's remove mingetty" crowd gets their way. (That also 
assumes that VT switching is working, which seems to not be the case 
with nvidia's POS video drivers :-(.)

-- 
Matthew
"NT was a marketing name that stood for New Technology, but it was still 
an amusing coincidence that WNT was VMS with each letter replaced by the 
next one."
   -- Jeremy Reimer

[Benjamin Lewis]

Matthew Woehlke wrote:
>  darrell pfeifer wrote:
> > 2008/9/12 Dr. Diesel <dr.diesel(a)gmail.com&gt;
> >
> >> Booting normally to GDM, using normal root login gives me unable to
> >> authenticate user.  If I boot to init3, my user/pass works just fine,
> >> then I
> >> can startx.  I attempted passwd and reset my pass with no luck!
> >>
> >> Anybody else?  Should I file this under GDM?
> >>
> >
> > The gdm changelog says
> >
> > * Tue Sep 09 2008 Jon McCann <jmccann(a)redhat.com&gt; - 1:2.23.92-2
> > - Disallow root login
> >
> >  So it is intentional
>  
>  So... what exactly are we supposed to do when the user login gets hosed?
>  Reach for a rescue disk? (Seriously, what's with the sudden trend to
>  make fixing problems harder by making recovery modes inaccessible in an
>  apparent bid to hide the "confusing/potentially dangerous" bits of the
>  system from the user?)
>   
CTRL+ALT+F1
Login as root there
fix it
CTRL+ALT+F7 to get back to GDM

-- 

Benjamin Lewis
ben.lewis(a)benl.co.uk

Ambassador, Fedora Project - http://fedoraproject.org

-----------------------------------------------------------------------
http://benl.co.uk./                                 PGP Key: 0x647E480C

"In cases of major discrepancy, it is always reality that got it wrong"
                                                        -- RFC 1118

[Martin Sourada]

On Sat, 2008-09-13 at 10:04 +0100, Benjamin Lewis wrote:
>  CTRL+ALT+F1
>  Login as root there
>  fix it
>  CTRL+ALT+F7 to get back to GDM
>   
Or boot to runlevel 3, login as root there and startx...

Martin