frank@zen.co.uk (Frank Wales) (09/27/89)
This posting is rather lengthy (>300 lines), and contains both
outstanding bugs in, and desirable enhancements to, HP-UX on the 800
series (much of this also applies to the 300 series). The purpose of
the posting is two-fold; to inform of problems which we have
encountered here (most of these have already been officially
registered with HP as SRs or ERs, but what the hell :-)), and to
solicit comments on the enhancement requests which are included. It
is not an exhaustive list; just the result of some of the problems
we've run up against recently.
All of the following are encountered on the current HP-UX release
on our model 840 [uname -a => HP-UX zen A.B3.10 D 9000/840 5067].
First, the *bugs*:
1) The information stored in "/etc/disktab" for the 7963
disk drive results in newfs(1M) correctly displaying that
the drive has 304MB of disk space (297108 1K blocks in section 2).
The device driver in the kernel contains the same information in
hp7959_sizes: section 2 has 1188432 256-byte blocks.
Yet once the disk has been formatted and mounted, bdf(1) reports only
278MB available. This leaves almost 10% of the physical disk space
unavailable, which is unacceptable for a drive of this capacity,
especially as larger drives (e.g., 7937s) have a much lower percentage
unavailable. Please make the device drivers do what the numbers say
they should, and access the whole disk. (See UK PICS call reference
E1319345.) Alternatively, please explain to me where the extra space
went, and offer suggestions on how I could reclaim some of it (I have
tried to make sense of the messages printed up during the formatting
process, but I can't make any combination of the numbers displayed
"fill in" the missing amount).
2) disksecn(1M) fails to recognise the names of any disk
drives, including all the examples in the manual. I understand this
is a known problem.
3) The file /etc/magic always gets overwritten when an update
is performed; this destroys any customer-added information in the file.
It would be preferable if the original /etc/magic file could be
preserved somewhere to make updating the new one easier, for example
by using a customise script to copy a new one from /etc/newconfig
after the original had been renamed to /etc/magic.old, say.
Another option would be to alter file(1) to read two files,
one reserved for vendor-provided information, and one for customer-
provided information; /etc/sysmagic and /etc/localmagic,
for example. [I class this as a bug because the behaviour is both
undocumented and unexpected, and costs me time at each system update;
a plain text configuration or data file such as this invites me to
add my own information, and so I expect updates to honour that.]
4) HP-UX is consistently shipped with inappropriate file
permissions (mostly on executables). Specifically, executables are installed
with read permission enabled. This violates the principle of minimum
information, and is a potential security problem, since unfriendly
Users can use the strings(1) utility to examine the data spaces
of executables (or indeed the entire files) for clues on how to defeat
protection mechanisms, for example.
*No* executable should be readable (or writable!).
Another example: because of unnecessarily liberal file permissions, it
is not hard to snoop on mail as it is being processed by sendmail(1M).
Denying 'other' read/search permissions on one directory solves the problem.
5) The Korn shell (ksh(1)) does not handle line editing at all
well in emacs mode. Specifically, if the cursor reaches the
end of the line, the prompt is lost when the line editor scrolls the
display to continue. Worse, if PS1 is longer than half
the COLUMNS value (40 on an 80-column terminal when no COLUMNS
value is set), then when the cursor reaches the right end of the line,
scrolling does not take place for the number of characters that the
length of PS1 exceeds half the length of COLUMNS by. So
if PS1 is 50 characters long on an 80-column terminal, the
scrolling will occur ten characters too late. In the meantime, garbage
characters are printed at the right end of the display line; pressing
^L doesn't help. The vanishing-prompt bug is fixed in ksh-88,
but I don't know about the long prompt bug.
6) The program getty(1M) does not accept the character ^H as a synonym for
#, which contradicts the manual entry. (Until recently, it didn't
accept ^U for @ either).
7) vipw(1M) does not recognise that /bin/ksh is a valid shell for root. At
the moment, it only accepts /bin/sh and /bin/csh. Also, vipw(1M) fails to
preserve the mode of /etc/passwd when it restores it from /etc/ptmp.
8) curses(3) does not handle HP terminals at all correctly,
especially when display enhancements are in use. This has been a
long-standing problem with hp-ux that shows little sign of
getting better. The screen updating algorithms are tuned to work
for terminals which have character-based rather than screen-based
attributes, and as a result can be made to fail badly on HP
terminals. They fail even without attributes, though, as the appended
example program shows. *Please* spend some time getting this repaired.
It is embarrassing to HP to have a product which supports DEC
terminals better than their own. We can supply many example
programs demonstrating bugs. Indeed, we already have, but the
responses to date have always been to patch curses to work
in the specific cases we have submitted, rather than to see the
big picture and fix all the problems. It is frustrating for our
applications developers whenever I update the operating system,
since they get sarcastic about what curses will do *this* time. :-(
Just for your amusement, here is one simple example:
#include <curses.h>
/*
* To run type cc -g <this file name> -o c_bug -lcurses && c_bug
*
* It fails when using a TERM value of 2392
*
* This program should print a message on the standard screen on line 0.
* The message should be erased and a new message written. Because the
* messages are sufficiently similar curses attempts an update and gets
* it wrong.
*
* Spurious characters appear before the "f". In this example there are
* 2 but by changing the y of the second addstr there will be no
* corruption, or 1, 2 or 3 characters inserted. The characters depend on
* the last character of the first `word' and they have the ascii value of
* 1st y - 2nd y + last char (e.g. 14-11+'X'= '[') up to 1st y == 6. When
* this value decreases the effect disappears.
*
* If the first word is shortened the effect changes then disappears.
* Adding any character to the end of the string has no effect.
*/
main()
{
initscr(); noecho(); cbreak(); nonl();
mvaddstr(0, 6, "XXXXXX X");
mvaddstr(LINES-2,10, "Press any key");
refresh();
getch(); /* wait for something before carrying on */
erase();
mvaddstr(0, 3, "XXXXXX f");
refresh();
endwin();
return 0;
}
9) The manual entries for login(1) and environ(5)
both incorrectly show default PATHs as having a null component.
This could mislead an inexperienced User into thinking that having
a null component in one's PATH is a required thing, or a good
idea. The manual entries should be amended to reflect the correct behaviour.
10) ksh(1), if interrupted at an inopportune moment,
will trash the stty settings of the controlling terminal. This manifests
itself as leaving off echo, and having the eof character changed to
^A. This comes about as a result of forgetting to restore
the termio structure, leaving, for example, c_cc[VEOF] as what was there
when it was regarded as c_cc[VMIN]. It is hard to duplicate
this easily, but it happens to me several times a day.
11) compress(1) fails to preserve the time of last modification of
a file if you don't own it, but have permission to compress (or
uncompress) it anyway%. This is because it executes chown(2) before
utime(2) when copying the old file's information across; swapping
the order of these calls fixes the problem. (This is a problem if, like us,
you have lots of source files lying around, and automatic compression
of files not in current use; programs like make(1) lose vital information
when the mtime is changed unexpectedly.)
%) Additionally, compress will let you compress a file you don't have
write permission for, as long as you have write permission in the
directory containing it (and can read the file). Either have compress
examine the file and reject attempts at compression of non-writable files,
or document this behaviour.
12) vi doesn't re-read line settings when re-starting from stopped.
Try stty erase ^H intr ^?, vi, <suspend> (^Z, probably),
stty erase ^? intr ^C, fg, :q, stty -a, and note that erase is ^H and
intr ^?.
13) The manual entry for init(1M) states that "Telinit can only be
run by someone who is super-user or a member of group 'sys'." I am
a member of group sys (gid 3), and executing telinit always gives me
the message "could not send a signal to init" if I am not also root at
the time.
%%
And now, the suggested enhancements:
1) The Number One Enhancement we want: please, *please* add
shared libraries to HP-UX. We want to get back to the days when
a program which opens a file, diddles some information and prints a
summary has an executable size less than 30K. We'd be ever so
grateful. [I understand this is planned for 7.0. If you have a list
of things that might not make it, make sure this is *not* on that list.]
2) sam(1M) should be customer-configurable. At the moment,
adding a new User on this machine involves updating more files that
just those in /etc. For example, /usr/lib/aliases and
/zen/lib/lasertab (a simple database for routing laser printer
requests). It also involves creating multiple directories and new
files with particular permissions, such as $HOME/public and
/usr/mail/$LOGINNAME. It may also involve non-standard User directory
information (some of our User directories are remotely mounted over
NFS). You get the idea. I would love to have a utility for
doing what sam does that I can configure to the needs of my system.
At the moment, it isn't sam.
(As a side comment, using JYACC as the menuing front-end leads to some
amusing (and annoying) inconsistencies. For example, it would be nice
to have the return key behave the same as the JYACC transmit key,
which is intuitive for most Users, but this is not allowed. It works
better for update(1M), which is *much* better than it used to be.
Thank you for that.)
3) Updating the rcs(1) program (and its cohorts ci(1), co(1), etc.)
to be the current version (4.6, at least) makes several new features available.
4a) Context-dependent files on the 800 series, recognisable over NFS,
would let us have a cleaner networked file system. So would remote booting
of any 300 or 800 diskless node from any other (diskful) node. [7.0 ?]
4b) A more recent version of NFS would ensure that we don't have
to hack the kernels of machines to which we want remote root access.
Alternatively, throwing NFS down the toilet and implementing a better
networking protocol would be nice (do I hear Domain/OS? :-)).
5a) Add support for HP9122 floppy disk drives on the 800 series (it sort of
works anyway, but support would be nice).
5b) Then, provide a set of MS-DOS utilities, in the spirit of the
existing LIF utilities.
6) Make id(1) accept options to print out selected information, such
as just the numeric uid or just the named egid. This will save a lot
of cut(1)ting and sed(1)ing in scripts. (We have written our own
version of this --- it is *much* more convenient.)
7) Alter finger(1) (chfn(1)) so that it works sensibly *off* the
Berkeley campus. In other words, make the restrictions on building
and telephone information a lot less specific than they currently are.
8) Enhance the security of the login(1) program by making it always
ask for a dial-up password on a line listed in /etc/dialups *even if*
the (loginname,password) tuple is invalid. At the moment, getting to
the Dialup-password: prompt tells an aspiring invader that they have
succesfully obtained a valid login name and associated password, yet
the login(1) program (quite correctly) does not reject an invalid
login name without asking for a password. The current behaviour is
both inconsistent and less secure than the suggested alternative.
9) mv(1) reports rename(2) failure when renaming a directory, and
the target directory name ends in `/'. This is a harmless name
extension which rename accepts on the source directory name,
and which open(2) also accepts on a directory name. Make
rename consistent in both opening and creation of directories.
Alternatively, make mv(1) strip the trailing `/' from the
destination argument. (Unless there's a good reason for this behaviour.)
[Also, why is /usr/lib/mvdir present, since mv(1) uses rename(2)?
Does something else use it?]
10) HP-UX and its associated products often have unstripped
executables; many programs on the distribution tapes contained
spurious symbolic information which takes up a lot of disk space
(after installation of the optional networking, database and compiler
products at 3.01, there were >2.5MB to be reclaimed by stripping in
/usr/bin alone).
11) man(1) creates cat(1)able manual entries which are
publicly writable; this is an invitation for potential mischief-makers.
Making the whole manual area non-writable (except by the man program,
etc.) would be of value.
12) Extend the -perm primary of find(1) to accept symbolic arguments
as chmod(1) does, and define the semantics such that +permissions
match permissions granted, -permissions match permissions denied, and
=permissions exactly matches the nominated permissions field. This
would allow, for example, detection of setuid programs with any
combination of other bits, or any writable executables without regard
for their overall permissions, much more easily than a string of
( -perm 211 -o -perm 611 -o -perm 121... ) does.
13) For the sake of tidiness, make all executables and system directories
owned by bin, and in group bin, unless specifically required otherwise.
14) Supply detailed update information, not just a summary. For
example, some programs which worked under 2.1 broke at 3.01 because of
a change in the semantics of the lockf(2) call. It took some
work to locate the change. A detailed list of bugs fixed and enhancements
added would suffice (note: the Software Status Bulletin is not
good enough to serve this purpose).
15) xargs invokes its program argument even if it has no subsequent
arguments on its stdin to pass along. There is no way of stopping this
behaviour except by specifying an invocation arg list of 1 (using the -l
option), which makes find | xargs almost as inefficient as
find ... -exec {}. Adding an option to xargs to abandon execution of
its arguments when its stdin is empty would be useful, and wouldn't
break whatever depended on this behaviour in the first place.
16) vi is less literate that it used to be before NLS came along;
if you type vi Bill Dave , then type i <escape> ZZ , you will
see the message:
"Bill" 1 characters, 1 lines, 1 more files to edit
which is worse than the standard Domesdos message "1 File(s) copied".
Anyone else annoyed by this?
There, that wasn't so bad. :-) It is perhaps a statement on the
overall quality of HP-UX that many of the above will seem like
fiddling details, but that doesn't mean they're not important to
at least one customer.
--
Frank Wales, Systems Manager, [frank@zen.co.uk<->mcvax!zen.co.uk!frank]
Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217 davidb@Pacer.UUCP (David Barts) (09/28/89)
In article <1717@zen.co.uk>, frank@zen.co.uk (Frank Wales) writes: > This posting is rather lengthy (>300 lines), and contains both > . . . > 4) HP-UX is consistently shipped with inappropriate file . . . > . . . *No* executable should be readable (or writable!). Shell scripts need BOTH read and execute permission; binaries only need execute. > . . . > [Also, why is /usr/lib/mvdir present, since mv(1) uses rename(2)? > Does something else use it?] > . . . Yes. Anything that moves directories in an SYS V compatible way. Rename(2) is a BSD-ism. -- David Barts Pacer Corporation davidb@pacer.uucp ...!fluke!pacer!davidb
ronw@hpuflfa.HP.COM (Ron Williams) (09/29/89)
> 1) The information stored in "/etc/disktab" for the 7963 > disk drive results in newfs(1M) correctly displaying that > the drive has 304MB of disk space (297108 1K blocks in section 2). > The device driver in the kernel contains the same information in > hp7959_sizes: section 2 has 1188432 256-byte blocks. > > Yet once the disk has been formatted and mounted, bdf(1) reports only > 278MB available. This leaves almost 10% of the physical disk space > unavailable, which is unacceptable for a drive of this capacity, > especially as larger drives (e.g., 7937s) have a much lower percentage > unavailable. Please make the device drivers do what the numbers say > they should, and access the whole disk. (See UK PICS call reference > E1319345.) Alternatively, please explain to me where the extra space > went, and offer suggestions on how I could reclaim some of it (I have > tried to make sense of the messages printed up during the formatting > process, but I can't make any combination of the numbers displayed > "fill in" the missing amount). Note that 'bdf' only reports the space available to *REGULAR* users, i.e. does not count the "minfree" space (default 10%) that is reserved for 'root'. You can use 'tunefs' to modify "minfree" even to 0 if that's what you want. Note also that performance of the file system typically begins to suffer as the capacity exceeds 85% full. Also the manpage for 'tunefs' indicates that setting "minfree" to 0 can cause up to a 3X performance hit. > 2) disksecn(1M) fails to recognise the names of any disk > drives, including all the examples in the manual. I understand this > is a known problem. As I understand the response I got from the same question, this was a "feature" that was intentionally added at 3.0. The *hand waving* included some discussion as to "we don't know what the user override parameters might be for block size etc. and therefore may print-out invalid information". I agree with you that it should work! Its the only real source of on-line information about the *FIXED* disc partitions in HP-UX/800. However, you can manually look in /etc/disktab and manually feed the parameters to 'disksecn' and still get the desired data but there is a significant chance for error. I assume that a fairly simple script could be written to automate it, scanning /etc/disktab, selecting info, feed to 'disksecn' by redirecting STDIN..... Ron Williams HP Ft. Lauderdale ronw@hpfcse ------------ TEL: T-938-2278 {hpfcse}!hpuflfa!ronw FAX: T-938-2293 COMSYS: 3179 AREA CODE: 305 HPDESK: Ron Williams / HP3179/07
renglish@hpisod2.HP.COM (Robert English) (09/29/89)
> / frank@zen.co.uk (Frank Wales) / 8:38 am Sep 27, 1989 / > ...once the disk has been formatted and mounted, bdf(1) reports only > 278MB available. This leaves almost 10% of the physical disk space > unavailable, which is unacceptable for a drive of this capacity... Berkeley file systems have a "minimum acceptable percentage of file system blocks." If the file system reaches that threshold, only the super-user can allocate blocks. Because of the way in which Berkeley file systems allocate blocks performance suffers considerably if the percentage of free blocks drops too low. See filsys(4) for details. If you still want to change the value, tunefs(1M) will allow you to do so. --bob-- renglish@hpda.hp.com
mjb%hoosier.utah.edu@cs.utah.edu (Mark Bradakis) (09/29/89)
In article <1717@zen.co.uk> frank@zen.co.uk (Frank Wales) writes: >1) The information stored in "/etc/disktab" for the 7963 >disk drive results in newfs(1M) correctly displaying that >the drive has 304MB of disk space (297108 1K blocks in section 2). >... >Yet once the disk has been formatted and mounted, bdf(1) reports only >278MB available. This leaves almost 10% of the physical disk space >unavailable I'm confused. Are you talking about the standard 10% extra space available only to system stuff, or another 10% on top of that, i.e., what if you did newfs -m 1% ... mjb. mjb@hoosier.utah.edu "I've seen some nasty deserts, Lord, but this one here's the worst!"
human@hpindda.HP.COM (Aaron Schuman) (09/29/89)
Frank> HP-UX is consistently shipped with inappropriate file Frank> permissions (mostly on executables). Frank> Specifically, executables are installed with read Frank> permission enabled. This violates the principle of Frank> minimum information, and is a potential security problem, Frank> since unfriendly users can use the strings(1) utility Frank> to examine the data spaces of executables (or indeed Frank> the entire files) for clues on how to defeat protection Frank> mechanisms, for example. Back in the old days, files were shipped with whatever permissions the developers put on them. Mistakes were made. Then we got smart about file permissions - security fiends got together with system integrators, defined default permissions for different classes of files, checked for exceptions, and required developers to justify exceptions. When we were establishing the defaults, we did consider the principle of minimum information. We decided leave executables readable because honest users have legitimate reasons to read executables (running /usr/bin/what to determine a version number before reporting a defect, for instance), and because dishonest users are quite likely to have access to some Unix-derived source code anyway. Even if it isn't HP-UX, it's probably similar. Frank> Another example: because of unnecessarily liberal file Frank> permissions, it is not hard to snoop on mail as it is Frank> being processed by sendmail(1M). Denying 'other' read / Frank> search permissions on one directory solves the problem. I read about that problem recently in Neil G.'s security mail list, and wrote to HP's sendmail expert immediately. He said: David> We do ship [the directory] world-readable/searchable. David> The configuration file we ship has always made the David> default queue file mode 600, plus if you don't set David> the default file mode at all, the default is also David> 600 (in previous releases, including 3.1, mode 000). David> If HP-UX sendmail is making the queue files world David> readable, it's being system-administrator-configured David> to do so. Your criticism of HP-UX is obviously carefully thought out, and it is well received here. I hope that somebody at HP responds to each of your concerns, but even if some of them are not addressed in replies to this note string, you can be sure that your ideas are quoted in e-mail sent to the people who are best able to implement them. I'd also like to thank you for describing security concerns in only as much detail as needed. In the past, others have reported security problems in notes in cookbook detail. To other readers of this note, please be discreet like Frank! If you discover a security defect, use notes to ask someone to contact you. Aaron Schuman HP-UX Trusted Networks
runyan@hpirs.HP.COM (Mark Runyan) (09/30/89)
>/ frank@zen.co.uk (Frank Wales) / 8:38 am Sep 27, 1989 / >3) Updating the rcs(1) program (and its cohorts ci(1), co(1), etc.) >to be the current version (4.6, at least) makes several new features available. Is there particular functionality that you need or want? Always happy to find that someone is using the program. Mark Runyan
frank@zen.co.uk (Frank Wales) (10/02/89)
In article <245@zircon.UUCP> davidb@Pacer.UUCP (David Barts) writes: >In article <1717@zen.co.uk>, frank@zen.co.uk (Frank Wales) writes: >> 4) HP-UX is consistently shipped with inappropriate file . . . >> . . . *No* executable should be readable (or writable!). > >Shell scripts need BOTH read and execute permission; binaries >only need execute. Sorry, maybe I was unclear; I use the terms "binary" and "executable" interchangably; when I say executable, I never mean anything which requires an interpreter. -- Frank Wales, Systems Manager, [frank@zen.co.uk<->mcvax!zen.co.uk!frank] Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217
frank@zen.co.uk (Frank Wales) (10/02/89)
[I knew I'd get some things wrong...] In article <1989Sep28.134347.17060@hellgate.utah.edu> mjb%hoosier.utah.edu@cs.utah.edu (Mark Bradakis) writes: >In article <1717@zen.co.uk> frank@zen.co.uk (Frank Wales) writes: >>1) The information stored in "/etc/disktab" for the 7963 >>disk drive results in newfs(1M) correctly displaying that >>the drive has 304MB of disk space (297108 1K blocks in section 2). >>... >>Yet once the disk has been formatted and mounted, bdf(1) reports only >>278MB available. This leaves almost 10% of the physical disk space >>unavailable > >I'm confused. Are you talking about the standard 10% extra space available >only to system stuff, or another 10% on top of that, i.e., what if you did >newfs -m 1% ... The minfree on most of our larger partitions (except /tmp and /) is typically 2 to 5%; as an experiment when reorganising our partitions for the 3.1 upgrade, I tried various combinations of minfree, fragment and block sizes on one of our 7963 packs, and even with 0% minfree, I couldn't get the available size above 278M. Here is an example line from bdf(1) on such a disk: Filesystem kbytes used avail capacity Mounted on /dev/dsk/c4d0s2 278874 224411 40519 85% /zen Note that the total of the used+avail is 264M, consistent with the 5% minfree I specified at newfs(1M) time. The number I was referring to is the 278874 kbytes. Since then, some mail I have received suggests that HP-UX's default inode allocation may be swallowing the space, and, having had a root around (:-)), this looks likely (we have an awful lot of inodes on that disk, and most seem to be waiting around for something to point to). Now, although I should have thought of this myself (I've been at this sys admin lark a few years now), this is the first time someone from HP suggested looking at the inode count, despite having officially called this in as a problem. At the next opportunity, I'll cut the number of inodes down by a chunk and see what happens. In article <4310060@hpindda.HP.COM> human@hpindda.HP.COM (Aaron Schuman) >Frank> HP-UX is consistently shipped with inappropriate file >Frank> permissions (mostly on executables). >Frank> Specifically, executables are installed with read >Frank> permission enabled. This violates the principle of >Frank> minimum information, and is a potential security problem, >Frank> since unfriendly users can use the strings(1) utility >Frank> to examine the data spaces of executables (or indeed >Frank> the entire files) for clues on how to defeat protection >Frank> mechanisms, for example. > >When we were establishing the defaults, we did consider >the principle of minimum information. We decided leave >executables readable because honest users have legitimate >reasons to read executables (running /usr/bin/what to >determine a version number before reporting a defect, >for instance), and because dishonest users are quite >likely to have access to some Unix-derived source code >anyway. Even if it isn't HP-UX, it's probably similar. Hmmm. Even though I see the point, I find it hard to agree with it. I'd rather make special arragements for programs like what(1) (setgid to bin, and binaries group-readable, say) than ship with loose permissions and expect sysadmins to tighten things up. It makes more sense to me to make it the responsibility of the customer to reduce security rather than increase it, especially as many sys admins I know are too busy or too trusting of the vendor-supplied system to actually go around and change things. (One customer of ours, for which I am developing a comms system, won't even change the GenericSysName login prompt. I am now wondering if all the care I've taken with access control, admin logging and other such things will ever get the chance to be appreciated.) Not every customer has the knowledge or the time to do these things, and, to me, it behooves the vendor to ship the tightest system possible, with documentation explaining how to reduce security and the trade-offs involved. To continue with your example of what(1) for a moment; no-one here can use it to determine program versions except sys admin staff, and no-one has ever complained about this. If someone has a legitimate reason for knowing the revision level of a particular program, I'll be only to happy to tell them. Moreover, executing what(1) on /usr/lib/sendmail here gives me what looks like an HP revision code; I really wanted to know if HP had shipped 5.61 sendmail yet. Having stringsed, then finally emacsed, the executable, if a version number of the form 5.anything is in there, I can't find it. But this is a separate complaint. ;-) [And now today's big gaffe (like a giraffe, but with a shorter neck)...] >Frank> Another example: because of unnecessarily liberal file >Frank> permissions, it is not hard to snoop on mail as it is >Frank> being processed by sendmail(1M). Denying 'other' read / >Frank> search permissions on one directory solves the problem. > >I read about that problem recently in Neil G.'s security mail >list, and wrote to HP's sendmail expert immediately. He said: > >David> The configuration file we ship has always made the >David> default queue file mode 600, plus if you don't set >David> the default file mode at all, the default is also >David> 600 (in previous releases, including 3.1, mode 000). >David> If HP-UX sendmail is making the queue files world >David> readable, it's being system-administrator-configured >David> to do so. David is correct; I now know this is a configurable option, I did not before -- o sole mea culpa :-). Such excuse as I can offer is that I did not prepare our current sendmail.cf file, and it is my avowed intention to one day obtain sufficient knowledge to be able to write new ones with cat. When I'm less busy writing products. Eventually. >I hope that somebody at HP responds to each of your concerns, but even >if some of them are not addressed in replies to this note string, you >can be sure that your ideas are quoted in e-mail sent to the people who >are best able to implement them. Sounds good to me; I look forward to seeing them all in 8.0 (modulo the wrong ones, of course). :-) -- Frank Wales, Systems Manager, [frank@zen.co.uk<->mcvax!zen.co.uk!frank] Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217
kamat@uceng.UC.EDU (Govind N. Kamat) (10/02/89)
In article <245@zircon.UUCP> davidb@Pacer.UUCP (David Barts) writes: > [Also, why is /usr/lib/mvdir present, since mv(1) uses rename(2)? > Does something else use it?] Yes. Anything that moves directories in an SYS V compatible way. Rename(2) is a BSD-ism. SYSV has /usr/lib/mv_dir, a binary which needs to be setuid root. I think Frank is talking about the *script* /etc/mvdir which needs to be run by root; there is no /usr/lib/mvdir on HP-UX. I don't think that script is needed, just as /etc/link and /etc/unlink are unnecessary; it is probably necessary for customers to point this out before HP gets rid of them. -- Govind N. Kamat College of Engineering kamat@uceng.UC.EDU University of Cincinnati Cincinnati, OH 45221, USA
kamat@uceng.UC.EDU (Govind N. Kamat) (10/02/89)
In article <4310060@hpindda.HP.COM> human@hpindda.HP.COM (Aaron Schuman) writes: Frank> Another example: because of unnecessarily liberal file Frank> permissions, it is not hard to snoop on mail as it is Frank> being processed by sendmail(1M). Denying 'other' read / Frank> search permissions on one directory solves the problem. David> We do ship [the directory] world-readable/searchable. If I remember correctly, the last HP-UX update (from 3.0 to 3.1) seemed to have its own ideas about this and changed the mode of our spool directory to 777. And that's not all -- the same treatment was given a number of other directories and files, and the /usr/local/man tree was summarily deleted. It's rather ridiculous if customers' filesystems are messed around with in such a callous manner. -- Govind N. Kamat College of Engineering kamat@uceng.UC.EDU University of Cincinnati Cincinnati, OH 45221, USA
scott@grlab.UUCP (Scott Blachowicz) (10/02/89)
In article <1989Sep28.134347.17060@hellgate.utah.edu> mjb%hoosier.utah.edu@cs.utah.edu (Mark Bradakis) writes: >In article <1717@zen.co.uk> frank@zen.co.uk (Frank Wales) writes: >>1) The information stored in "/etc/disktab" for the 7963 >>disk drive results in newfs(1M) correctly displaying that >>the drive has 304MB of disk space (297108 1K blocks in section 2). >>... >>Yet once the disk has been formatted and mounted, bdf(1) reports only >>278MB available. This leaves almost 10% of the physical disk space >>unavailable >I'm confused. Are you talking about the standard 10% extra space available >only to system stuff, or another 10% on top of that, i.e., what if you did >newfs -m 1% ... Also, space for inodes is taken out. You could decrease the number of inodes allocated by increasing the "bytes-per-inode" value with newfs. I usually find that the defaults end up with LOTS of inodes, but your mileage may vary... -- Scott Blachowicz E-mail: scott@grlab.UUCP USPS: Graphicus ..or.. ...!hpubvwa!grlab!scott 150 Lake Str S, #206 VoicePh: 206/828-4691 Kirkland, WA 98033 FAX: 206/828-4236
mjs@hpfcso.HP.COM (Marc Sabatella) (10/04/89)
>And now, the suggested enhancements: > >1) The Number One Enhancement we want: please, *please* add >shared libraries to HP-UX. We want to get back to the days when >a program which opens a file, diddles some information and prints a >summary has an executable size less than 30K. We'd be ever so >grateful. [I understand this is planned for 7.0. If you have a list >of things that might not make it, make sure this is *not* on that list.] You have unfortunately been misinformed. Shared libraries were never planned for 7.0, although we are currently working toward getting them into 8.0. Do not consider this statement to be a commitment to providing shared libraries for 8.0, but we do hope to be able to do so. The shipment dates for 8.0 are up in the air, so please do not turn around now and ask, "when does 8.0 come out"? -------------- Marc Sabatella HP Colorado Language Lab (CoLL) marc@hpmonk
shankar@hpclscu.HP.COM (Shankar Unni) (10/04/89)
> >Shell scripts need BOTH read and execute permission; binaries > >only need execute. > > Sorry, maybe I was unclear; I use the terms "binary" and "executable" > interchangably; when I say executable, I never mean anything which > requires an interpreter. Binaries may need read permission, too, if, for instance, a program ever needs to access one's own text space using file I/O. Typical uses for such a feature are: (a) accessing the linker symbol table (of course, the binary must not be stripped for this). (b) dynamic loading (using ld -A) (the same restriction applies). In general, however, I agree with you - binaries should have --x--x--x permissions. ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar
johnny@hpcuhc.HP.COM (Johnny Klonaris) (10/05/89)
> Your criticism of HP-UX is obviously carefully thought out, > and it is well received here. I hope that somebody at HP > responds to each of your concerns, ... This is being done... -jk