[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug #23053



Turbo wrote:
> What if I do it the '{user|group}add' way when I change the files? (I haven't
> looked into it yet, but...). I prefer not to start doing systemcall's, exec's
> etc, if I can avoid it...

First...

If you need to call another executable (which you _must_ in this case), you
should use exec; you are absolutely right on the money when you say you don't
want to use system. You are asking, pretty much over and over, "can I directly
edit /etc/passwd, shadow, group, etc?" and the reply is "no" :) 

NOW, HAVING SAID THAT...

What if _common_ methods were provided which the shadow passwd suite would 
actually use to do the edits? Make them really robust and REALLY fast, and
make them accessible from perl.

THE POINT BEING:

Since the data structure for login authentication should be allowed to change,
Only One Interface For Changing Them should be provided, so that any interface
ON TOP OF that can be created.

QUESTION TO ALL: Is the shadow passwd suite an acceptable interface for this 
purpose?

Here's my take: I have typically 1,700 students enrolled in the department
for which the lab I control is used. 1,700 students == 1,700 groups. Try adding
that many groups to your system using groupadd and you'll see immediately (no,
not immediately, in about a half hour) why groupadd is not great. Now add the
1,700 students. No problem: newusers is quite fast. Next, add groups, one
per class section. Now, put 1,700 students into those groups; each student 
into each group for his/her class section. Then tell me (an hour later) you
liked that :)

I know that the shadow passwd suite can be compiled to allow the use of db
files instead of text files. Upon presenting this idea on IRC, one of you
(James Troup, I believe) said: nononononononono... if you do that, you can't
edit them by hand.

But: the whole idea behind "ALWAYS use the interface" is "The underlying data
structure should be allowed to change without the need to change every package
that accesses the data structure."

So... can we compile up a suite that's pam-able and installable and switch-
back-and-forth-able which uses db (or dbm or gdbm or whatever) files?

-Jim


--
To UNSUBSCRIBE, email to debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: