<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 04/12/2013 18:51, Rick Stevens a
écrit :<br>
</div>
<blockquote cite="mid:529F6BB0.1010004@alldigital.com" type="cite">On
12/03/2013 11:47 PM, Michael Schwendt issued this missive:
<br>
<blockquote type="cite">On Tue, 03 Dec 2013 23:08:04 +0100, Jehan
Procaccia wrote:
<br>
<br>
<blockquote type="cite">hello
<br>
I use about a hundred fedora19 stations in computer labs at
our school
<br>
users accounts comes from an ldap directory and the homedir is
<br>
automounted via NFS.
<br>
However, recently I noticed that on some stations, local user
account
<br>
had been created !
<br>
looking at the log file, I discovered in /var/log/secure
something like
<br>
this:
<br>
<br>
/accounts-daemon: request by system-bus-name ::1.733
<br>
[/usr/libexec/gnome-initial-setup pid:15259 uid:991]: create
user 'foobar'//
<br>
//useradd[29724]: new group: name=foobar, GID=1001//
<br>
//secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: new
user:
<br>
name=susana, UID=1001, GID=1001, home=/home/susana,
shell=/bin/bash//
<br>
//secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add
'susana' to
<br>
group 'wheel'//
<br>
//secure-20131117:Nov 15 17:16:43 b3-4 useradd[29724]: add
'susana' to
<br>
shadow group 'wheel'/
<br>
<br>
Scary ! how comes gnome-initial-setup could create users, and
morever
<br>
add them to the wheel group !
<br>
could it be a bug in /gnome-initial-setup , /a feature side
effect ? or
<br>
our students found a "back door" ?
<br>
any suggestion greatly appreciated .
<br>
</blockquote>
<br>
See what running
<br>
<br>
/usr/libexec/gnome-initial-setup --force-new-user
<br>
<br>
does on one of your installed machines, where 'susana' has not
been active
<br>
before. Normally, it would prompt for the root password before
creating a
<br>
new account, but perhaps something else happens with your setup.
<br>
</blockquote>
<br>
In the old days, a process called 'firstboot' was run immediately
upon
<br>
the first boot after a fresh install. firstboot was responsible
for a
<br>
number of things, but one of them was setting up the first user
account
<br>
and adding it to the "wheel" group because it was expected to be
the
<br>
administrator's account. firstboot never asked for the root
password as
<br>
it assumed it was being run as part of the install process by a
human
<br>
who installed the system and would already know the root password.
<br>
Hence, the first user account was, by default, an administrative
<br>
account in the wheel group who could sudo any command.
<br>
<br>
Once firstboot had been run, it disconnected itself from the boot
<br>
process by deleting a file in the root of the filesystem that an
init
<br>
script looked for. If the file wasn't there, firstboot wouldn't
run.
<br>
<br>
I don't run gnome (because it's so damned bloated), so I'm not
sure what
<br>
gnome-initial-setup does, but I suspect it took its cues from the
old
<br>
firstboot mechanism. If so, then what probably happened is that
the install process was interrupted after the OS was installed.
Whoever did
<br>
the install did NOT go through the first boot. "susana" was
probably the
<br>
first person to see the machine, booted it and got the first boot
thing.
<br>
She added herself, not knowing exactly what this meant at the
time. I
<br>
doubt she was being malicious.
<br>
<br>
These are just guesses, mind you, but seem to be a likely
scenario.
<br>
----------------------------------------------------------------------
<br>
- Rick Stevens, Systems Engineer, AllDigital
<a class="moz-txt-link-abbreviated" href="mailto:ricks@alldigital.com">ricks@alldigital.com</a> -
<br>
- AIM/Skype: therps2 ICQ: 22643734 Yahoo:
origrps2 -
<br>
-
-
<br>
- A day for firm decisions!!! Well, then again, maybe
not! -
<br>
----------------------------------------------------------------------
<br>
</blockquote>
This senario is very possible<br>
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<br>
and that the "firstboot" process didn't finished properly .<br>
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<br>
"<i>it disconnected itself from the boot
</i><i><br>
</i><i>
process by deleting a file in the root of the filesystem that an
init
</i><i><br>
</i><i>
script looked for. If the file wasn't there, firstboot wouldn't
run.</i>"<br>
what is its name ?<br>
<br>
could this pb be relatated to:<br>
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=968582">https://bugzilla.redhat.com/show_bug.cgi?id=968582</a><br>
not sure, because on a station that has the pb it seems disabled:<br>
<br>
# /bin/systemctl status initial-setup-text.service<br>
initial-setup-text.service - Initial Setup configuration program
(text mode)<br>
Loaded: loaded
(/usr/lib/systemd/system/initial-setup-text.service; disabled)<br>
Active: inactive (dead)<br>
<br>
and I do run my kickstart with<br>
firstboot --disabled<br>
<br>
if you have other suggestions on how to prevent my users to create
local "wheel" account , let me know !<br>
<br>
Thanks .<br>
</body>
</html>