dce@mips.COM (David Elliott) (09/20/88)
It turns out that the System V (or at least SVR3) version of the
passwd command will cause the resultant passwd file to be mode
0444. I have had a couple of complaints about this, and would like
to decide on a solution.
Is it reasonable to have passwd fix the mode of the new /etc/passwd
to be the same as the current /etc/passwd?
--
David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dcelvc@cbnews.ATT.COM (Lawrence V. Cipriani) (09/20/88)
In article <3394@dunkshot.mips.COM> dce@mips.COM (David Elliott) writes: > ... >I have had a couple of complaints about this [/bin/passwd changes mode of >/etc/passwd explicitly to 0444 -lvc], and would like to decide on a solution. >Is it reasonable to have passwd fix the mode of the new /etc/passwd >to be the same as the current /etc/passwd? No, unless you don't give a darn about security. What exactly is your complaint about mode 0444 on /etc/passwd? Anything one should be allowed to do to /etc/passwd should be done by root or the owner of /etc. A carefully coded suid to root should do the job. Please elaborate what your need is. >David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce -- Larry Cipriani, AT&T Network Systems, Columbus OH, cbnews!lvc lvc@cbnews.ATT.COM
marc@ima.ima.isc.com (Marc Evans) (09/21/88)
In article <1235@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes: >No, unless you don't give a darn about security. What exactly is your >complaint about mode 0444 on /etc/passwd? Anything one should be allowed >to do to /etc/passwd should be done by root or the owner of /etc. A >carefully coded suid to root should do the job. Please elaborate what your >need is. > >Larry Cipriani, AT&T Network Systems, Columbus OH, cbnews!lvc lvc@cbnews.ATT.COM My personal opinion is that /etc/passwd should be mode 0644, owned by root, and the /etc directory should be mode 0755 owned by root as well. The reason for this is to facilitate shell scripts that have become popular such as /etc/vipw, which can only be executed by the user root. This allows generic users to read the file as needed, while the administrator (root) is allowed to modify things without having to forcably overwrite the file (ie - in vi, :w! instead of :w). Unfortunately, with the advent of networks and things like YP, this script only helps with half of the problem, but this is a whole different discussion... =============================================================================== Marc Evans | decvax<--\ /-->marc<--\ | That's not a bug...It's Synergytics| harvard<--\ / \ /--->norton | a design feature... 8-) Pelham, NH | necntc<---->ima<---->symetrx<---->dupont | ======================= ===============================================================================
meo@stiatl.UUCP (Miles O'Neal) (09/21/88)
In article <3394@dunkshot.mips.COM>, dce@mips.COM (David Elliott) writes: > > It turns out that the System V (or at least SVR3) version of the > passwd command will cause the resultant passwd file to be mode > 0444. I have had a couple of complaints about this, and would like > to decide on a solution. I suggest you tell the complainers to always leave the passwd file 0444. NOBODY besides root should have access to that, and root can always w! from vi to force a write. User-friendly interfaces can set their uid to root, as long as they are smart enough not to become dangerous, or TOO friendly to non-root users...
tim@attdso.ATT.COM (Tim J Ihde) (09/21/88)
In article <3394@dunkshot.mips.COM> dce@mips.COM (David Elliott) writes: > >It turns out that the System V (or at least SVR3) version of the >passwd command will cause the resultant passwd file to be mode >0444. > >David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce This is not a bug. You sure don't want anybody to be able to write to that file (gives them root access in a hurry), and if you turn off read permission LOTS of programs will not work right (like 'ls'). 0444 is the proper mode for /etc/passwd. Your system is just the way it is supposed to be as of SVR3. Eventually the actual encoded password may get moved to another (non-readable) file, but this is not currently the case. Wait for R4. -- Tim J Ihde att!attdso!tim (201) 898-6687 tim@attdso.att.com This disclaimer intentionally left blank. attmail!tihde
dce@mips.COM (David Elliott) (09/21/88)
In article <1235@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes: >In article <3394@dunkshot.mips.COM> dce@mips.COM (David Elliott) writes: >> > ... >>I have had a couple of complaints about this [/bin/passwd changes mode of >>/etc/passwd explicitly to 0444 -lvc], and would like to decide on a solution. >>Is it reasonable to have passwd fix the mode of the new /etc/passwd >>to be the same as the current /etc/passwd? > >No, unless you don't give a darn about security. What exactly is your >complaint about mode 0444 on /etc/passwd? Anything one should be allowed >to do to /etc/passwd should be done by root or the owner of /etc. A >carefully coded suid to root should do the job. Please elaborate what your >need is. I have no complaint. I have no need. Maybe I should make it clearer. A customer of ours who uses BSD Unix complained that "something" was changing the mode of /etc/passwd from 0644 (which he set it to) to 0444. I believe that the complaint was that he had to use ":w!" in vi (I know, vi'ing the password file is wrong, but we haven't had time to add a vipw program yet). On the other hand, let's remember what we're talking about here. If I want to create a file whose name contains spaces, Unix lets me. If I want to set up a file with mode 0002, Unix lets me. This is one of the aspects of the Unix philosophy. Why should Unix change the mode of my password file if I set it to something explicitly? This isn't a case of security. If he has to, this customer is going to set up a cron job to "fix" the mode of /etc/passwd because that's the mode he wants it to have. -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
jsp@marvin.UUCP (Johnnie Peters) (09/23/88)
In article <3394@dunkshot.mips.COM>, dce@mips.COM (David Elliott) writes: > > It turns out that the System V (or at least SVR3) version of the > passwd command will cause the resultant passwd file to be mode > 0444. I have had a couple of complaints about this, and would like > to decide on a solution. > > Is it reasonable to have passwd fix the mode of the new /etc/passwd > to be the same as the current /etc/passwd? It is entirely reasonable for passwd to set the modes of /etc/passwd to 0444. I fyou don't believe this try working for a company like Unisys in O.S. support for unix. The first time a customer calls and says things like: I just accidentaly deleted my passwd file. What can I do? I saved the passwd file and now it wont let anybody on. What do I do? I forgot the root password. What do I do? you will understand why the passwd file is protected as well as possible. What you say, "That can never happen to me!!!!! I know what I am doing!!!!!!!" Well I know what I am doing and a few days ago spent an hour restoring miscelaneous files because of a "MINOR" mistake. You will too one day. -- Johnnie --
rwhite@nusdhub.UUCP (Robert C. White Jr.) (09/23/88)
in article <588@attdso.ATT.COM>, tim@attdso.ATT.COM (Tim J Ihde) says: > Your system is just the way it is supposed to be as of SVR3. Eventually > the actual encoded password may get moved to another (non-readable) file, > but this is not currently the case. Wait for R4. In SVR3.2.1 (which I just got) you get a file called /etc/shadow which contains all the password information, and a maintence program to do all the mucking about with password you would like. You also get password aging by days instead of weeks. And you should SEE what they did to lp (et. al.) They have forms, transformation filters (automatic), print wheel/font cartredge support, most standard options, allow/deny users to printers forms and filters, automatic printer selection by all of the above, and terminfo definitions for printers (including GRAPHICS and microspacing). They did, however, mess up one thing REAL BAD! Only lp or root can mount forms/fonts! AT&T and I are having a little talk about the bad part, so we will see. Rob.
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (09/23/88)
In article <3441@dunkshot.mips.COM> dce@dunkshot.UUCP (David Elliott) writes: > ... (I know, >vi'ing the password file is wrong, but we haven't had time to add a vipw >program yet). >David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce Ooops...this is what I do all the time. Why is it wrong? Where do I get vipw? Seriously, please educate me. Thanks in advance Dan -- Daniel A. Graifer Franklin Capital Investments uunet!fciva!dag 7900 Westpark Drive, Suite A130 (703)821-3244 McLean, VA 22102
rogerk@mips.COM (Roger B.A. Klorese) (09/24/88)
In article <423@fciva.FRANKLIN.COM> dag@fciva.UUCP (Daniel A. Graifer) writes: >In article <3441@dunkshot.mips.COM> dce@dunkshot.UUCP (David Elliott) writes: >> ... (I know, >>vi'ing the password file is wrong, but we haven't had time to add a vipw >>program yet). >Ooops...this is what I do all the time. Why is it wrong? Where do I get >vipw? BSD. (In MIPS' case, it means that that's a program we haven't yet tackled on the path to our merged RISC/os kernel.) -- Roger B.A. Klorese MIPS Computer Systems, Inc. {ames,decwrl,prls,pyramid}!mips!rogerk 25 Burlington Mall Rd, Suite 300 rogerk@mips.COM (rogerk%mips.COM@ames.arc.nasa.gov) Burlington, MA 01803 I don't think we're in toto any more, Kansas... +1 617 270-0613
dce@mips.COM (David Elliott) (09/24/88)
In article <7@marvin.UUCP> jsp@marvin.UUCP (Johnnie Peters) writes: > It is entirely reasonable for passwd to set the modes of /etc/passwd >to 0444. I fyou don't believe this try working for a company like Unisys >in O.S. support for unix. The first time a customer calls and says things >like: > > I just accidentaly deleted my passwd file. What can I do? > > I saved the passwd file and now it wont let anybody on. What > do I do? > > I forgot the root password. What do I do? > >you will understand why the passwd file is protected as well as possible. I don't buy it. I've worked in OS support for Unix for my entire career, and yes I've heard these same questions. Of all of these, only the first comment gives a reason to have the password file protected in this way (protecting the file won't keep them from breaking the file or forgetting the root password, will it?), and only then because they have to say "rm -f /etc/passwd" or answer "y" when asked to remove it. This isn't protecting against truly unfortunate accidents. I have no problem with shipping the password file as mode 0444, and if the user leaves that alone, there's no problem. If the user really wants that file to be mode 0644, they may just decide to go out of their way to keep it that way. -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/25/88)
In article <344@stiatl.UUCP> meo@stiatl.UUCP (Miles O'Neal) writes: >I suggest you tell the complainers to always leave the passwd file >0444. NOBODY besides root should have access to that The complaint here is not about security or lack thereof, it's about programs undoing the system administrator's actions. There is nothing more secure about a 0444 /etc/passwd than a 0644 one, but there are programs which aren't smart enough to know that you can write an "unwritable" file if uid==0 (vi is an example). Some people like the "extra work" required to write to a 0444 file, but if so, they can chmod it themselves. Where should this "enforced security" end? Should /bin/passwd also chmod / to 555 mode as well? And what about /etc/? Should "ls" remove world write permission from /dev/mem if it happens to discover it? -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
chris@cetia.UUCP (Chris Bertin) (09/26/88)
To change the mode of a file without being requested to is one thing, but
SYSV does much better when it comes to the 'utmp' handling. For fun, do
$ cp /etc/passwd /tmp
$ ls -l /tmp/passwd
$ who /tmp/passwd
$ ls -l /tmp/passwd
If the utmp code finds that the file you are doing 'who' on is not in 'utmp'
format, it ZEROES the file!!! Thank you AT&T.
The code is in libc/gen/getut.c. The wonderful comment says:
/* Make sure file is a multiple of 'utmp' entries long */
and if the file is not a multiple, it does an 'unlink' and a 'creat'...
Chris
--
Chris Bertin | CETIA
| 150, Av Marcelin Berthelot, Z.I. Toulon-Est
+33(94)212005 | 83088 Toulon Cedex, France
Ext: 239 | inria!cetiameo@stiatl.UUCP (Miles O'Neal) (09/26/88)
In article <423@fciva.FRANKLIN.COM>, dag@fciva.FRANKLIN.COM (Daniel A. Graifer) writes: > >vi'ing the password file is wrong, but we haven't had time to add a vipw > >program yet). > > Ooops...this is what I do all the time. Why is it wrong? Where do I get > vipw? There is nothing _wrong_ with that. It requires that you know what you are doing, and pay attention to what you are doing; that's all. I have been administering systems for a long time, and UNIX systems for 3 years, and have yet to make a major screw up (knock on wood (ie, my head] in /etc/passwd or /etc/group. I cannot say the same for all of the programs that were supposed to make life easier for me, and be safer to boot. Two of them I have seen were almost guaranteed to screw things up, and, while handy for novice administrators, or non-computer types, they were much slower than editing vi. On a related note, the Sun 386i interface for adding users puts them somewhere else altogether, in a related file called yppasswd, or something like that. Handy for network administration, but a nuisance to those of us used to doing it the UNIX way (my O.S., right or wrong. 8*) ) ===================================================================== Miles O'Neal decvax!gatech!stiatl!meo
sullivan@vsi.UUCP (Michael T Sullivan) (09/27/88)
In article <131@cetia.UUCP>, chris@cetia.UUCP (Chris Bertin) writes: > > If the utmp code finds that the file you are doing 'who' on is not in 'utmp' > format, it ZEROES the file!!! Thank you AT&T. This is not the case on our 3B2/400 running SVR3.1. -- Michael Sullivan {uunet|attmail}!vsi!sullivan V-Systems, Inc. Santa Ana, CA sullivan@vsi.com Just say to yourself over and over, "President Quayle". I can't do more than 2.
jbayer@ispi.UUCP (id for use with uunet/usenet) (09/27/88)
In article <131@cetia.UUCP>, chris@cetia.UUCP (Chris Bertin) writes:
.
. To change the mode of a file without being requested to is one thing, but
. SYSV does much better when it comes to the 'utmp' handling. For fun, do
.
. $ cp /etc/passwd /tmp
. $ ls -l /tmp/passwd
. $ who /tmp/passwd
. $ ls -l /tmp/passwd
.
. If the utmp code finds that the file you are doing 'who' on is not in 'utmp'
. format, it ZEROES the file!!! Thank you AT&T.
who is non-destructive on SCO Xenix. I just tried it.
Jonathan Bayer
Intelligent Software Products, Inc.lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (09/28/88)
In article <4827@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > In article <344@stiatl.UUCP> meo@stiatl.UUCP (Miles O'Neal) writes: > >I suggest you tell the complainers to always leave the passwd file > >0444. NOBODY besides root should have access to that > > The complaint here is not about security or lack thereof, it's about > programs undoing the system administrator's actions. I can sympathize with this, as I used to administer many UNIX(R) machines. However, the story we have gotten from our customers (ie. the people that pay the bills), and I imagine that other products have, is that they want the security policies built into the system. Security policies are being implemented in software because that's what the market is demanding. Like it or not administrators are going to lose more ground here. > Where should this "enforced security" end? Should /bin/passwd also > chmod / to 555 mode as well? And what about /etc/? Should "ls" > remove world write permission from /dev/mem if it happens to discover > it? There are programs that are designed to enforce (or at least complain about wrong) file/directory permissions. Some have the capability to be customized site by site. I tend to prefer one that just complains and lets me worry about what it ought to be. -- Larry Cipriani, AT&T Network Systems, Columbus OH, cbnews!lvc lvc@cbnews.ATT.COM
bernie@codas.att.com (Bernie Brown) (09/28/88)
In article <873@vsi.UUCP>, sullivan@vsi.UUCP (Michael T Sullivan) writes: > In article <131@cetia.UUCP>, chris@cetia.UUCP (Chris Bertin) writes: >> >> If the utmp code finds that the file you are doing 'who' on is not in 'utmp' >> format, it ZEROES the file!!! Thank you AT&T. > > This is not the case on our 3B2/400 running SVR3.1. Thanks for pointing this out, Michael. The problem did exist in SVR0 and possibly SVR2 but is definitely gone in SVR3. -- Bernie Brown bernie@codas.att.com
ccdn@levels.sait.edu.au (DAVID NEWALL) (09/28/88)
In article <4827@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > The complaint here is not about security or lack thereof, it's about > programs undoing the system administrator's actions. > > Where should this "enforced security" end? Should /bin/passwd also > chmod / to 555 mode as well? And what about /etc/? Should "ls" > remove world write permission from /dev/mem if it happens to discover > it? I haven't got the sources, so I don't know for sure... I imagine passwd writes a _brand new_ copy of /etc/passwd. So it's not a case of passwd "happening to discover" that the mode isn't 444. On the contrary, it's a case of passwd not noticing that the mode is other than 444. ------------------------------------------------------------------------- David Newall Phone: +61 8 343 3160 South Australian Institute of Technology Fax: +61 8 349 6939 The Levels, South Australia, 5095 E-mail: ccdn@pisa.sait.oz.AU
sbc@sp7040.UUCP (Stephen Carroll) (10/03/88)
In article <384@levels.sait.edu.au>, ccdn@levels.sait.edu.au (DAVID NEWALL) writes: ] In article <4827@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: ] > The complaint here is not about security or lack thereof, it's about ] > programs undoing the system administrator's actions. ] > ] > Where should this "enforced security" end? Should /bin/passwd also ] > chmod / to 555 mode as well? And what about /etc/? Should "ls" ] > remove world write permission from /dev/mem if it happens to discover ] > it? ] ] I haven't got the sources, so I don't know for sure... I imagine passwd ] writes a _brand new_ copy of /etc/passwd. So it's not a case of passwd ] "happening to discover" that the mode isn't 444. On the contrary, it's a ] case of passwd not noticing that the mode is other than 444. according to the sources, David is correct. Passwd creates a copy of /etc/passwd as /etc/ptmp, and makes the changes for the new passwd there. After the passwd has been changed and verified, passwd links /etc/passwd to /etc/opasswd, and then unlinks /etc/passwd. It then links /etc/ptmp to /etc/passwd and unlinks /etc/ptmp. It does all this with umask set to 0333, thereby ensuring a new file with mode 444. So it's not really a case of not noticing that the old mode had been changed, but really a case of not caring. If security is really a concern at all, this is the only way (besides setting umask to 0777 1/2 :-) which this should work. ] ------------------------------------------------------------------------- ] David Newall Phone: +61 8 343 3160 ] South Australian Institute of Technology Fax: +61 8 349 6939 ] The Levels, South Australia, 5095 E-mail: ccdn@pisa.sait.oz.AU