| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 9332.1 | There is only one executable | NETRIX::"[email protected]" | Ann Majeske | Mon Mar 31 1997 11:47 | 10 |
| Obviously, since passwd, chfn, and chsh are hard linked there is only one
executable. As far as I know, this has always been the case. Other
people don't seem to have a problem with using chsh to only change the
shell, etc. If you want any help you're going to have to supply more
information. Be specific about what you're trying to do and give detailed
information on what is happening. Including a copy of an actual terminal
session illustrating the problem is always a good idea. You should also
give the version of Digital UNIX you are using, and any relevant
configuration information (e.g., are you using NIS?).
[Posted by WWW Notes gateway]
|
| 9332.2 | Same executable for passwd, chsh and chfn | USCTR1::16.178.0.28::Workbenchuser | | Mon Mar 31 1997 21:40 | 23 |
| Hi,
The issue is such that the customer want to disable
the use of chsh for his users. He started by changing
the permission flag of chsh, without realizing that passwd
too take effect and passwd is also disable.
Now, deleting chsh will not be useful since the user
can create the link again.
I think it poses a significant problem in environment when
users are not allow to change shell, or change finger
information. Putting the three functionality together in
a single executable will not be a good idea, since you
can't disable each functionality individually.
As for my customer, he is running DU 3.2G, Enhanced Security,
no NIS. It's seems that 3.2C, 3.2D and 4.0B have the same
problem.
For the case of my customer. Please advise if there is any
specific way to disable chsh.
|
| 9332.3 | | finder.uvo.dec.com::COFFEYJ | La Feline Flooz - a unix cat | Tue Apr 01 1997 07:48 | 6 |
| sounds like a case for moving chsh somewhere else and
replacing it with a blank no permissions file, or a link
to date or some such...
any reason why they couldn't do that? (asked of someone
out there who would d know?)
|
| 9332.4 | /etc/shells | QUARRY::reeves | Jon Reeves, UNIX compiler group | Tue Apr 01 1997 14:52 | 1 |
| Can't you just nuke most of /etc/shells except whatever shells are "approved"?
|
| 9332.5 | Same executable for passwd, chsh and chfn | USCTR1::16.178.16.23::BENGHUI | | Tue Apr 01 1997 21:02 | 16 |
| sounds like a case for moving chsh somewhere else and
replacing it with a blank no permissions file, or a link
to date or some such...
...
Even moving chsh to anywhere else isn't really going
to help much. Since anyone can do a link to passwd
as chsh. Such as...
$ ln -s /usr/bin/passwd chsh
$ ./chsh
Old shell: /bin/sh
....
|
| 9332.6 | same executable for passwd, chsh, and chfn | USCTR1::16.178.0.150::BENGHUI | | Wed Apr 02 1997 00:17 | 7 |
| Can't you just nuke most of /etc/shells except whatever shells are "approved"?
...
Hmm... can't do that for their environment.
Since I can't nuke all the interactive shells,
especially bourne for root.
|
| 9332.7 | | BIGUN::nessus.cao.dec.com::Mayne | A wretched hive of scum and villainy | Wed Apr 02 1997 18:15 | 6 |
| Editing /etc/shells does not remove shells, it just limits the shells that users
can chsh to, which sounds exactly like what you want.
See the man page for chsh.
PJDM
|
| 9332.8 | Wait a minute... | QUARRY::reeves | Jon Reeves, UNIX compiler group | Wed Apr 02 1997 19:00 | 2 |
| If they don't have an interactive shell, how can they do chsh in the
first place?
|
| 9332.9 | same executable for passwd, chsh and chfn | USCTR1::16.178.16.69::BENGHUI | | Wed Apr 02 1997 21:42 | 39 |
| If they don't have an interactive shell, how can they do chsh in the
first place?
...
Here's the situation...
The key idea is to provide the user from changing their
default shell. The default shell is a restricted shell
running a lynx menu frontend for certain tools such as
pine, tin, ftp, and other stuffs. For certain reason,
the user is able to run specific commands to change their
default shell to an interactive shell via chsh.
The customer wish to remove the functionality of chsh
but it seems to be tied with passwd. Upon changing
the permission flag of chsh, passwd is disable for
the user too.
There is a few solutions that I can think of... one of
which is to write a version of passwd that doesn't
have chsh functionality and remove the original passwd,
chsh, and chfn. Another is to put wrapper around chsh
& passwd.
Remove entries from /etc/shells doesn't seems to be a
solution because there are staffs on the system that
has interactive shells access. I tested the behaviour
on DU 3.2C that if the user's shell is not on /etc/shells
list, the default /bin/sh will be used. I thought it will
be nice if there user will logoff with a invalid shell
error instead.
As you highlighted, how they can do chsh? the customer
is trying to figure that out too.
I ask if there is any significant advantage of having
passwd, chsh and chfn been the same program other than
version control. Please advise...
|
| 9332.10 | I'm still confused. | QUARRY::reeves | Jon Reeves, UNIX compiler group | Thu Apr 03 1997 14:55 | 14 |
| There are two scenarios here.
1. The restricted shell lets them run any arbitrary command. In this case,
the user could just run "csh" as a command, so what difference does it make
that they can run chsh?
2. The restricted shell only allows certain commands to be run. In this
case, just disable chsh.
Are they relying on the pathetic security model of "Rsh"? If that's the
case, just take "." out of the PATH and chsh out of path-accessible places
(maybe ln, too) and a link won't be possible.
I still see a non-problem in search of a non-solution.
|