On 12/04/2013 01:42 PM, Jehan Procaccia issued this missive:
Le 04/12/2013 18:51, Rick Stevens a écrit :
On 12/03/2013 11:47 PM, Michael Schwendt issued this missive:
On Tue, 03 Dec 2013 23:08:04 +0100, Jehan Procaccia wrote:
hello
I use about a hundred fedora19 stations in computer labs at our school
users accounts comes from an ldap directory and the homedir is
automounted via NFS.
However, recently I noticed that on some stations, local user account
had been created !
looking at the log file, I discovered in /var/log/secure something like
this:
/accounts-daemon: request by system-bus-name ::1.733
[/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create user
'foobar'//
//useradd[29724]: new group: name=foobar, GID=1001//
//secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new user:
name=susana, UID=1001, GID=1001, home=/home/susana, shell=/bin/bash//
//secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to
group 'wheel'//
//secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add 'susana' to
shadow group 'wheel'/
Scary ! how comes gnome-initial-setup could create users, and morever
add them to the wheel group !
could it be a bug in /gnome-initial-setup , /a feature side effect ? or
our students found a "back door" ?
any suggestion greatly appreciated .
See what running
/usr/libexec/gnome-initial-setup --force-new-user
does on one of your installed machines, where 'susana' has not been
active
before. Normally, it would prompt for the root password before
creating a
new account, but perhaps something else happens with your setup.
In the old days, a process called 'firstboot' was run immediately upon
the first boot after a fresh install. firstboot was responsible for a
number of things, but one of them was setting up the first user account
and adding it to the "wheel" group because it was expected to be the
administrator's account. firstboot never asked for the root password as
it assumed it was being run as part of the install process by a human
who installed the system and would already know the root password.
Hence, the first user account was, by default, an administrative
account in the wheel group who could sudo any command.
Once firstboot had been run, it disconnected itself from the boot
process by deleting a file in the root of the filesystem that an init
script looked for. If the file wasn't there, firstboot wouldn't run.
I don't run gnome (because it's so damned bloated), so I'm not sure what
gnome-initial-setup does, but I suspect it took its cues from the old
firstboot mechanism. If so, then what probably happened is that the
install process was interrupted after the OS was installed. Whoever did
the install did NOT go through the first boot. "susana" was probably the
first person to see the machine, booted it and got the first boot thing.
She added herself, not knowing exactly what this meant at the time. I
doubt she was being malicious.
These are just guesses, mind you, but seem to be a likely scenario.
This senario is very possible
we installed our station automatically (cobbler2 kickstart + cfengine3
for post config) and remotely , it is possible that some stations didn't
finish correctly the install process
and that the "firstboot" process didn't finished properly .
Do you know how to check on a station if the "firstboot process" state
is still "on" or "off", what about that mysterious file you mention
"/it disconnected itself from the boot //
//process by deleting a file in the root of the filesystem that an init //
//script looked for. If the file wasn't there, firstboot wouldn't run./"
what is its name ?
On old systems (e.g. CentOS 5/6), the /etc/rc.d/init.d/firstboot script
looked for an /etc/sysconfig/firstboot file. That file would contain
either
RUN_FIRSTBOOT=YES
to run firstboot, or
RUN_FIRSTBOOT=NO
so it didn't run. Also, if the /etc/reconfigSys file was present, then
firstboot would be run with the "--reconfig" option.
Again, I don't run gnome (I'm an XFCE user) so I don't know if it's a
systemd service that should run and then remove itself or what. To be
honest, I haven't done a fresh Fedora installation (F18 or F19) in a
while (I've "fedup"ped already installed systems).
could this pb be relatated to:
https://bugzilla.redhat.com/show_bug.cgi?id=968582
not sure, because on a station that has the pb it seems disabled:
# /bin/systemctl status initial-setup-text.service
initial-setup-text.service - Initial Setup configuration program (text mode)
Loaded: loaded (/usr/lib/systemd/system/initial-setup-text.service;
disabled)
Active: inactive (dead)
It'd be interesting to bring up a system and see if that service is set
to start on the first boot after an install.
and I do run my kickstart with
firstboot --disabled
That may not have an effect as I don't think there is a "firstboot"
thing since we went to systemd/systemctl rather than the classic init
scripts. I think that initial-setup-text.service and/or the
gnome-initial-setup thing may have replaced that. Since I never installed
Gnome, I don't have the gnome-initial-setup program nor do I seem to
have a initial-setup-text.service file.
I wish I could be of more help.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- UNIX is actually quite user friendly. The problem is that it's -
- just very picky of who its friends are! -
----------------------------------------------------------------------
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
