[EMAIL PROTECTED] tapota :
> I recently installed Savane for use on an internal project. After having
> things running on a test machine I installed on an established machine.
> Things were running smoothly until we started adding users. Then user home
> directories and all their contents started disappearing.
>
> Some users happened to register close to when the sv_groups and sv_users
> script were to be run by cron. In sv_users we find this bit of code:
>
> my @to_be_removed;
> foreach my $user (@well_known) {
> # First test: looks for the typical case when someone is no
> # longer member of any project: we just list
> # Second test: looks for the marked as D users
> if (!exists($db_user_group{$user}) || $db_user{$user}->[5] eq 'D') {
> push(@to_be_removed, $user);
> }
> }
>
> Now, what happened is that we had established users on the system with
> established home directories from before the installation of Savane. As an
> internal machine I wasn't too worried about people having /bin/bash shell
> access. Also, the new user page says to use an existing account name if you
> have one when you register. So people used their accounts; why duplicate them?
In fact, people are advise to use the same login name for cohesion
sake (for instance, it's easier to follow users at cern.ch if they use
their AFS account name). But Savane backend has not be designed to
reuse existing unix accounts. In other words, the backend is only
grabbing data from the database and making the system fitting with it,
but not taking care of the system already in place.
In some way, doing so could lead to security issues, since there's no
way to be sure that's an account preexisting on a system belongs to
the person that freshly created the account via the web frontend.
> So, they register, don't join an established group fast enough, and
> this bit of code sees that the user is in @well_known since they
> exist both in /etc/passwd from their preexisting account as well as
> in the database because they just joined up. It also sees that they
> don't belong to a group and it adds them to @to_be_removed. Then the
> script proceeds to obliterate their home directory, login, etc. Yes,
> we thankfully had backups.
>
>
>
> This behavior, however, seems to be based on a rather bad
> assumption. There may be cases where users have business being local
> users even if they don't have an active project. Maybe you want the
> system to shoot an email off to an administrator, or maybe the user
> should just be stripped of all Savane specific groups on the
> filesystem. Maybe you really like the way it is and just want to put
> a big warning in the INSTALL.verbose file. Anything is better than
> leaving this assumption unchecked or unmentioned to those who don't
> fall into it.
I agree that we should *at least* document this behavior.
We could even an an extra test on the backend that verify if the home
directory was created by the backend on not (we can verify that, as
the backend always add a placeholder ~/.savannah), with the option to
skip that test of (that could slow things down and make no sense on
system where all users are managed via Savane).
Account deletion could be optional two. We could add an option were
all users get an account and no test is made to make sure they belong
to an active group. This option currently does not exist since nobody
needed it, but that should not be complicated to implement.
I opened a bug on our tracker (you should receive a Cc).
Regards,
--
Mathieu Roy
+---------------------------------------------------------------------+
| General Homepage: http://yeupou.coleumes.org/ |
| Computing Homepage: http://alberich.coleumes.org/ |
| Not a native english speaker: |
| http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english |
+---------------------------------------------------------------------+
