jhensley@isis.cs.du.edu (John 'Hawg' Hensley) (05/02/91)
I've got a few questions about my new PC-MINIX 1.5: apologies if they're FAQ, but I don't recall having seen their answers anywhere. 1) make doesn't work. Everything I've tried it on ends up with: Make: error code 32512 2) mail doesn't seem to work unless /usr/spool/mail and all the mailboxes are world-writable. If I install uucp and use an alternate mailer, can I avoid this? It's not a big deal, 'cause only friends are using the system, and they're not likely to delete each other's mailboxes, but it's the principle of the thing. This brings up another question -- is there something in the manual that says what permissions important dirs and files should have? I know, I know -- if you have to ask, you shouldn't be running UNIX, but some of the people who buy MINIX do it to learn just this sort of stuff, don't they? 3) I managed to install the Clam shell, using the binary version, but its savehist doesn't seem to work. I've tried savehist=50 and SAVEHIST=50 in both the .login and .clamrc files, but no luck. Also, when I tried compiling Clam by hand, it asked for a libtermcap.a; what is it and where can I find it? (I'm assuming it's not part of the standard distribution, as I put all of that on the disk.) 4) ps doesn't work -- do I need to rebuild my kernel so it has something to look at? (I'm just guessing here, 'cause it asks for some file that I can't find or remember now -- arrgh!) If it matters for any of this, I'm using an ancient ARC XT clone, 8MHz 8088, with 640K and a 32M Seagate (I think it's the ST138R, but it's been a while since I checked). ----- John Hensley "Every day somebody's asking questions, someone wants jhensley@isis.cs.du.edu to know if I know, all the answers or am I just guessing, guess we'll never really know" -- Huesker Due
gpvos@cs.vu.nl (Gerben 'P' Vos) (05/06/91)
jhensley@isis.cs.du.edu (John 'Hawg' Hensley) writes: >2) mail doesn't seem to work unless /usr/spool/mail and all the mailboxes > are world-writable. If I install uucp and use an alternate mailer, > can I avoid this? It's not a big deal, 'cause only friends are using > the system, and they're not likely to delete each other's mailboxes, > but it's the principle of the thing. Maybe you can apply the sticky directories patch and make /usr/spool/mail sticky, so anyone can write and create files, but only the owner of a file (and root) can remove it. Would this work? Is this The Right Thing to do? Any other directories that would be a candidate for becoming sticky, apart from this one and /tmp? . . . . . . . . . . . . . . . . . . . . . . . . . . . G e r b e n V o s <>< Aconet: BIGBEN!Gerben Vos Internet: gpvos@cs.vu.nl R.I.P. Radio Canada International 1942-1991
bert@arrakis.nl.mugnet.org (Bert Laverman) (05/10/91)
In article <9852@star.cs.vu.nl>, gpvos@cs.vu.nl (Gerben 'P' Vos) wrote: > jhensley@isis.cs.du.edu (John 'Hawg' Hensley) writes: >> [ description of need for world-writable mboxes ] > Maybe you can apply the sticky directories patch and make /usr/spool/mail > sticky, so anyone can write and create files, but only the owner of a file > (and root) can remove it. > Would this work? Is this The Right Thing to do? It probably would work, but it's _not_ the way to go. /usr/bin/mail is (or should be) setuid root, and can therefore create and access all mailboxes without any problems. It also chowns them to their owner, so with -rw------- access, only the owner of a mailbox can read it. > Any other directories that would be a candidate for becoming sticky, apart > from this one and /tmp? How about /usr/tmp? ;-) Greetings, Bert ===================================================================== Bert Laverman email: bert@arrakis.nl.mugnet.org tel.: +31 50 - 733587 or: laverman@cs.rug.nl =====================================================================
ralf@ptavv.ka.sub.org (Ralf Wenk) (05/11/91)
In article <9852@star.cs.vu.nl> gpvos@cs.vu.nl (Gerben 'P' Vos) writes: > jhensley@isis.cs.du.edu (John 'Hawg' Hensley) writes: > >>2) mail doesn't seem to work unless /usr/spool/mail and all the mailboxes >> are world-writable. If I install uucp and use an alternate mailer, >> can I avoid this? It's not a big deal, 'cause only friends are using >> the system, and they're not likely to delete each other's mailboxes, >> but it's the principle of the thing. > > Maybe you can apply the sticky directories patch and make /usr/spool/mail > sticky, so anyone can write and create files, but only the owner of a file > (and root) can remove it. > Would this work? Is this The Right Thing to do? > Any other directories that would be a candidate for becoming sticky, apart > from this one and /tmp? If you use wmail Fred van Kempen's wmail you do not need this. Wmail is installed as: -rwsr-xr-x 5 root system 42282 May 1 18:12 /usr/bin/mail /usr/spool/mail has the following owner and rights: drwxrwxr-x 2 daemon daemon 144 May 11 13:41 mail and the mailboxes created by wmail looked like -rw------- 1 postmast user 16 Sep 15 1990 postmaster -rw------- 1 ralf user 29012 May 11 13:41 ralf -rw------- 1 root root 0 May 1 18:13 root -rw------- 1 uucp uucp 16 Sep 15 1990 uucp So if you do not allow a login as daemon noone except root can remove a mailbox. The current version of wmail is in the plains archive. -- -- Ralf Wenk -- ralf@ptavv.ka.sub.org
rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) (05/13/91)
In article <9105102589@arrakis.nl.mugnet.org> bert@arrakis.nl.mugnet.org (Bert Laverman) writes: >In article <9852@star.cs.vu.nl>, gpvos@cs.vu.nl (Gerben 'P' Vos) wrote: >> jhensley@isis.cs.du.edu (John 'Hawg' Hensley) writes: >>> [ description of need for world-writable mboxes ] >> Maybe you can apply the sticky directories patch and make /usr/spool/mail >> sticky, so anyone can write and create files, but only the owner of a file >> (and root) can remove it. >> Would this work? Is this The Right Thing to do? >It probably would work, but it's _not_ the way to go. /usr/bin/mail is >(or should be) setuid root, and can therefore create and access all mailboxes >without any problems. It also chowns them to their owner, so with -rw------- >access, only the owner of a mailbox can read it. > My $0.02, I'd make it setgid mail. Then the mbox is user mail -rw-rw---- This would seem to be a little more secure than having /usr/bin/mail a setuid root program. This is how it works on my Sys V R3.2 box. -- Mike Dobson, Sys Admin for | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30 AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb or nrd0mxd@vmnmdsc WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com
kevin@nuchat.sccsi.com (Kevin Brown) (05/15/91)
In article <1991May13.124327.21919@nmrdc1.nmrdc.nnmc.navy.mil> rdc30@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) writes: >In article <9105102589@arrakis.nl.mugnet.org> bert@arrakis.nl.mugnet.org (Bert Laverman) writes: [discussion about the Right Way To Handle Mail deleted] >>It probably would work, but it's _not_ the way to go. /usr/bin/mail is >>(or should be) setuid root, and can therefore create and access all mailboxes >>without any problems. It also chowns them to their owner, so with -rw------- >>access, only the owner of a mailbox can read it. >> >My $0.02, I'd make it setgid mail. Then the mbox is user mail -rw-rw---- >This would seem to be a little more secure than having /usr/bin/mail a >setuid root program. This is how it works on my Sys V R3.2 box. This won't work with Minix as it exists out of the box. The reason is that not only does it have to be able to write existing mailboxes (which is taken care of by the setgid option you mention) but it also has to be able to create new mailboxes. This won't work unless you're sending mail to yourself :-). The reason for all that is that the chown() system call requires root privs under Minix. Under System V, it doesn't, but instead checks to see whether or not the owner of the file (or root) is trying to change the file's ownership. On systems without disk quota, the approach taken by System V is the Right Answer (IMHO). But the System V approach leads to problems on systems that implement disk quota (you want more space? chown your files to root! :-)... >Mike Dobson, Sys Admin for | Internet: rdc30@nmrdc1.nmrdc.nnmc.navy.mil -- Kevin Brown Disclaimer: huh? kevin@nuchat.sccsi.com kevin@taronga.hackercorp.com Minix -- the Unix[tm] of the 90's. System V -- the Multics of the 90's. :-)
peter@ficc.ferranti.com (Peter da Silva) (05/16/91)
In article <1991May14.202411.3372@nuchat.sccsi.com> kevin@nuchat.sccsi.com (Kevin Brown) writes: > On systems without disk quota, the approach taken by System V > is the Right Answer (IMHO). But the System V approach leads to problems on > systems that implement disk quota (you want more space? chown your files to > root! :-)... That depends on how they implement disk quota. There are two basic approaches: by user ID, or by directory tree. Each of them has problems, but at least doing it by directory tree doesn't force you to make chown su only. Of course if you can get your file into someone else's directory tree you can blow your quota... but if you can do that you can cause other problems anyway, so what's the point? -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
protonen@daimi.aau.dk (Lars J|dal) (05/16/91)
kevin@nuchat.sccsi.com (Kevin Brown) writes: [...] >The reason for all that is that the chown() system call requires root privs >under Minix. Under System V, it doesn't, but instead checks to see whether >or not the owner of the file (or root) is trying to change the file's >ownership. On systems without disk quota, the approach taken by System V >is the Right Answer (IMHO). But the System V approach leads to problems on >systems that implement disk quota (you want more space? chown your files to >root! :-)... [...] Doesn't this approach give a security problem (whether or not you have quotas)? As I see it, you could just make your brilliant hackerprogram suid and then change the owner to root! If the approach has been used in a real UNIX system, of course an obvious problem like this would have been foreseen at implementation :-), so I must be misunderstanding something. What? +--------------------------------------------------------------------------+ | Lars J|dal | (put your favourite quotation here) | | protonen@daimi.aau.dk | | |--------------------------------------------------------------------------| | Computer Science Department - Aarhus University - Aarhus - Denmark | +--------------------------------------------------------------------------+
kevin@nuchat.sccsi.com (Kevin Brown) (05/17/91)
In article <1991May16.093136.11171@daimi.aau.dk> protonen@daimi.aau.dk (Lars J|dal) writes: >kevin@nuchat.sccsi.com (Kevin Brown) writes: >[...] >>The reason for all that is that the chown() system call requires root privs >>under Minix. Under System V, it doesn't, but instead checks to see whether >>or not the owner of the file (or root) is trying to change the file's >>ownership. On systems without disk quota, the approach taken by System V >>is the Right Answer (IMHO). But the System V approach leads to problems on >>systems that implement disk quota (you want more space? chown your files to >>root! :-)... >[...] > >Doesn't this approach give a security problem (whether or not you have >quotas)? As I see it, you could just make your brilliant hackerprogram >suid and then change the owner to root! The System V approach removes any suid bits when it does its thing (I just tested this). >| Lars J|dal | (put your favourite quotation here) | -- Kevin Brown Disclaimer: huh? kevin@nuchat.sccsi.com kevin@taronga.hackercorp.com Minix -- the Unix[tm] of the 90's. System V -- the Multics of the 90's. :-)