Subject: Shadow problems

From: Michael Meskes <[email-masked]>
Date: Sat, 17 Aug 1996 13:27:55 +0200 (MET DST)

I'm currently trying to finish the work on the shadow package. However,
there are some decision to make:

1) Should we change the login package to be shadow aware? Or should shadow
come with its own login (that works with and without shadow password files)?
Or should we use the shadow login as standard?

I'm not sure which is the better one. I did change the standard login to be
shadow aware (easy) but I'm not sure about all the other features it has.
There are quite a lot of additional checks in the shadow login. Does anyone
has some info about this? Marek? Guy?

2) The login package also contains newgrp which has to be changed to be
shadow aware. The shadow package comes with its own newgrp source (much more
C code). So here's the same problem as under 1). Also there's the securetty
conffile that has to be included in both packages if we allow shadow to
install its own login and newgrp.

3) We definitely have to use the shadow passwd source to be able to handle
the shadowed passwd file, while the old one is needed for the standard
passwd file. But the passwd package also contains a conffile (/etc/shells)
and two more binaries that are not affected by shadow (vipw/vigr). Should I
add these to the shadow package, too?

4) Finally, how do I correctly set up the control file? I take it the
'Breaks:' option isn't implemented yet. But shadow breaks older version of
all packages that check the password.

Michael
-- 
Michael Meskes                   |    _____ ________ __  ____
[email-masked] |   / ___// ____/ // / / __ \___  __________
[email-masked]                  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[email-masked]                |  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!                | /____/_/      /_/  /____/\___/_/  /____/

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Sat, 17 Aug 1996 14:07:14 +0200 (MET DST)

> Or should we use the shadow login as standard?

Well the login we're using now is from util-linux, and unless you can get
the shadow patches into the upstream source (which wouldn't be a bad idea)
it would be easier to use the login from the shadow package I think.
You can use the Replaces: header for that. The same goes for newgrp.
In fact I think you can drop newgrp since it isn't needed under Linux, we
have BSD groups support.
> add these to the shadow package, too?

vipw and vigr should be rewritten so that they can edit the passwd+shadow.
I've got a vipw that merges passwd+shadow, lets you edit the merge, and
then splits it again. It also adheres to the shadow password locking
convention. If you want it drop me a line.

Also, you'll have to replace adduser ofcourse. This will be easy; shadow
comes with a command line utility "useradd" that just needs a simple
perl wrapper around it that emulates adduser functionality.

Bruce (I think it was Bruce) mentioned that we want shadow passwords as
a standard feature for 1.2; so I think just making sure all conflicting
packages get upgraded to work with shadow and letting shadow conflict
with the older packages would do the job.

Which reminds me: RedHat is going to integrate PAM into their next release.
Perhaps now is a good time to look if we should consider using that too,
or if we think that shadow is good enough for now.

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:[email-masked]          http://www.cistron.nl/
[email-masked] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

---

From: Michael Alan Dorman <[email-masked]>
Date: Sat, 17 Aug 1996 12:02:46 -0400

>or if we think that shadow is good enough for now.

Someone's already compiled libpam for Debian---I guess the question is
just whether or now we feel it's advisable to do this now.

I browse the PAM mailing list, but I don't have a feel for whether
it's ready for use or not---though RedHat is pretty quick about
releases, so I would guess that if it's not it will soon be ready.

I think that we should use it if it is.

Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."

---

From: Rob Browning <[email-masked]>
Date: 17 Aug 1996 11:37:36 -0500

> In fact I think you can drop newgrp since it isn't needed under Linux, we

Hmm, I often use newgrp when I'm about to do a set of actions where I
want to make sure all the new files get a particular group.  For
example, say I'm building a package in my home directory and I want
all the files created to be group src because I'm likely to move them
to /usr/src/ later.

Is there some other way to achieve this?

--
Rob

---

From: Michael Meskes <[email-masked]>
Date: Sun, 18 Aug 1996 15:15:35 +0200 (MET DST)

> In fact I think you can drop newgrp since it isn't needed under Linux, we

But then I think we shoudl keep newgrp just for compatibility.

> convention. If you want it drop me a line.

Yes. Of course I'm interested. Could you either send it to me via email or
place it in my directory on yar or upload it to my ftp site
(feivel.informatik.rwth-aachen.de) and drop me a line please?

> perl wrapper around it that emulates adduser functionality.

For the first step it seems to be easier to add a call to useradd to the
adduser script we're using already. 

> with the older packages would do the job.

That should be a Breaks: not a Conflicts: entry. But since we don't have
Breaks: ...

> or if we think that shadow is good enough for now.

If we can get PAM, too, I'm all for integrating it. What has to be done?

Michael

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Mon, 19 Aug 1996 09:42:12 +0200 (MET DST)

> Is there some other way to achieve this?

You can ofcourse make the new directory setgid (chmod g+s). All files
created in that directory will have their gid set to that of the directory..

But I can see that using newgrp might be more convenient

Mike.

---

From: Rob Browning <[email-masked]>
Date: 19 Aug 1996 02:48:40 -0500

> But I can see that using newgrp might be more convenient

Right.  The gid bit trick works fine unless you're running some set of
commands that may create a bunch of directories.  Then I don't think
the sgid bit will propagate.

--
Rob

---

From: Ian Jackson <[email-masked]>
Date: Sat, 24 Aug 96 18:29 BST

> the sgid bit will propagate.

It does.

Ian.