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(a)alldigital.com -
- 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! -
----------------------------------------------------------------------