Re: PAMmed su still broken for passwordless accounts
> > 1) su on passwordless accounts. > >(a) `su ' now bogusly prompts for a password. It lets > >you in if you type an empty password. > >(b) `echo somecommand | su ' now bogusly prompts for > >a password. su doesn't find a password, and exits without printing > >anything or running `somecommand'. I use the latter form a lot. Feature, not bug. PAM has been told to use "unix" authentication. You can override this by setting su authrequiredpam_permit.so instead of su authrequiredpam_unix.so try_first_pass in /etc/pam.conf. For situations where some accounts have passwords and some don't, play with the third word - "required" may become "sufficient" etc. > (2) static linkage of rshd. Previously, only static linkage of many other > > commands that are linked to libpam was broken (ftpd was one). Those patches of yours look reasonable. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -u patch
-On [20010426 23:27], Matt Dillon ([EMAIL PROTECTED]) wrote: >There is a whole lot more to doing an efficient copy then simply checking >the mtime. It's silly to try to integrate it into 'cp'. Use cpdup >instead. plug plug plug. That's missing the point. This is for script compatibility where people idiotically depend on cp -u to be standard. But basically I don't give a flying h00t or two whether or not it enters the source tree. -- Jeroen Ruigrok van der Werven/Asmodai --=-- asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best http://www.freebsd.org/doc/en_US.ISO_8859-1/books/developers-handbook/ Geef me die lach waarvoor je mij gewaarschuwd hebt... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAMmed su still broken for passwordless accounts
On Sat, 28 Apr 2001, Mark Murray wrote:
> > > 1) su on passwordless accounts.
> > >(a) `su ' now bogusly prompts for a password. It lets
> > >you in if you type an empty password.
(a1) It also lets you in if you type garbage followed by a newline.
> > >(b) `echo somecommand | su ' now bogusly prompts for
> > >a password. su doesn't find a password, and exits without printing
> > >anything or running `somecommand'. I use the latter form a lot.
>
> Feature, not bug. PAM has been told to use "unix" authentication.
The bug turns out to be that PAM shouldn't have been told this. The
non-PAM case uses the following check to avoid checking for passwords
on passwordless accounts:
---
/* if target requires a password, verify it */
if (*pwd->pw_passwd) {
---
but the PAM case always calls pam_authenticate() (for non-root).
> You can override this by setting
>
> su authrequiredpam_permit.so
>
> instead of
>
> su authrequiredpam_unix.so try_first_pass
>
> in /etc/pam.conf.
>
> For situations where some accounts have passwords and some don't, play
> with the third word - "required" may become "sufficient" etc.
The first form is equivalent to making all accounts passwordless. I don't
see how changing the third word could affect this.
login(1) uses the same configuration as su(1) in pam.conf but handles
passwordless accounts correctly. In login.c, most of the complications
for PAM authorization are in the auth_pam() function, and "goto
ttycheck;" skips over all types of authorization when there is no
password. The corresponding code in su.c is a tangle of ifdefs and
large inline code for PAM authorization.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PAMmed su still broken for passwordless accounts
> > Feature, not bug. PAM has been told to use "unix" authentication.
>
> The bug turns out to be that PAM shouldn't have been told this. The
> non-PAM case uses the following check to avoid checking for passwords
> on passwordless accounts:
> ---
> /* if target requires a password, verify it */
> if (*pwd->pw_passwd) {
> ---
> but the PAM case always calls pam_authenticate() (for non-root).
Right. To avoid a pam/other "turf" fight. I'll do the above until we
can fix the pams to allow a 'if no password, let him in' mode for
the pam_unix module.
> The first form is equivalent to making all accounts passwordless. I don't
> see how changing the third word could affect this.
Er, yes :-)
The pam modules need a mode for this. I'll do that.
> login(1) uses the same configuration as su(1) in pam.conf but handles
> passwordless accounts correctly. In login.c, most of the complications
> for PAM authorization are in the auth_pam() function, and "goto
> ttycheck;" skips over all types of authorization when there is no
> password. The corresponding code in su.c is a tangle of ifdefs and
> large inline code for PAM authorization.
I need to take out some of that #ifdef hell. For one, KERBEROS is no
longer needed. (fixed locally). WHEELSU needs to be properly documented.
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
No Subject
> OK, I;ve looked and looked and can't seem to figure out how to set hw.ata.wc to enabled. I've put and a few other things in /etc/sysctl.conf, the others get set, hw.ata.wc doesn't. You can't change it by hand either as sysctl tells you it's readonly. Grepping in /sys/i386/conf has turned up nothing and neither has grepping /boot. Have you tried specifying it in /boot/loader.conf ? hw.ata.wc="1" HTH (and have as much fun as possible :-), Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Experiences with new dir allocation on FFS?
[ resending, with a subject ] > OK, I;ve looked and looked and can't seem to figure out how to set hw.ata.wc to enabled. I've put and a few other things in /etc/sysctl.conf, the others get set, hw.ata.wc doesn't. You can't change it by hand either as sysctl tells you it's readonly. Grepping in /sys/i386/conf has turned up nothing and neither has grepping /boot. Have you tried specifying it in /boot/loader.conf ? hw.ata.wc="1" HTH (and have as much fun as possible :-), Salvo P.S. Apologies for the previous subjectless message. Because of my current ISP's ahem "policy", I am using another ISP's webmail services for sending mail. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Experiences with new dir allocation on FFS?
Erick Kinnee wrote: > On Sat, Apr 28, 2001 at 09:24:40AM -0500, Erick Kinnee wrote: > > No flames please, I feel I have tried to find the answer. :) > > Ok, I do deserve a flame it seems. I totally missed man ata. The > loader.conf manpage does state that there are 4 sysctl knobs tuneable > from there. So thanks to the folks that pointed out man ata. > > Feeling like a knob himself, > Erick For what it's worth, my tweaks to this enable changing this at runtime. It works nicely. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
camcontrol stop / restart broken
Hi, My source disk is quite noisy so normally I stop it after building the world and restart it once a week. Couple weeks this restart hasn't worked as before. Only way to start disk again is reboot. camcontrol stop 1:2:0 Unit stopped successfully mount /f mount: /dev/da1s1e: Input/output error tail /var/log/messages Apr 28 23:01:40 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack Apr 28 23:01:40 cat /boot/kernel/kernel: da1: reading primary partition table: error reading fsbn 0 camcontrol start 1:2:0 Unit started successfully mount /f mount: /dev/da1s1e: Input/output error ahc0: port 0xd400-0xd4ff mem 0xefffe000-0xefffefff irq 11 at device 9.0 on pci0 aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0xdc00-0xdcff mem 0xe000-0xefff irq 11 at device 9.1 on pci0 aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs da1 at ahc0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 11.626MB/s transfers (5.813MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 2048MB (4194995 512 byte sectors: 255H 63S/T 261C) da0 at ahc1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 5.813MB/s transfers (5.813MHz, offset 15), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) -- SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 ESPOO, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: [EMAIL PROTECTED]+358 9 52556252 fax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CVSup snapshot 16.1a is now available
Some of you who use CVSup might wish to consider upgrading to the new snapshot, called version 16.1a. It contains fixes for a number of bugs, including ... ... the one that sometimes caused CVSup to delete the symbolic link to your ports tree and replace it with a new copy of the tree. For the entire list of changes, see the "ChangeLog" file in the source distribution. As the term "snapshot" implies, this is not quite up to the standards of a real release. There is some stuff in it that's only half baked, and it's not tested as well as an actual release. However, it works fine for me and it contains some useful fixes. I have created a port "net/cvsup-devel" which you can use to build the snapshot. The source distribution itself is available on most FreeBSD FTP mirrors in the directory /pub/FreeBSD/development/CVSup/snapshots Before somebody asks, this snapshot is available in source form only. If I had time to deal with binaries, I would have made an official release. So buck up, and no whining. I know you can handle it. ;-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ipfw: several equal rules under same number bug
How it can be possible? ipfw -a l: 07001 401680 deny tcp from any to any 7006 070010 0 deny tcp from any to any 7006 070010 0 deny tcp from any to any 7006 I use equal "ipfw add" several times from the script, but the rule number was the same all times. I expect that rule is replaced, not added with same number several times. Who is our ipfw guru at this moment? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw: several equal rules under same number bug
Andrey A. Chernov wrote: > I use equal "ipfw add" several times from the script, but > the rule number was the same all times. I expect that rule > is replaced, not added with same number several times. No. There can be multiple rules with the same number. If you run multiple "ipfw add" commands with the same number, they are stored (and executed) in the order in which they were added. Having multiple =identical= rules with the same number doesn't make too much sense, since -- as you noticed -- the ones after the first will never match (unless the rule has a "count" action, in which case all of the identical rules will match). Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Experiences with new dir allocation on FFS?
On Sat, 28 Apr 2001, Bruce Evans wrote: > On Fri, 27 Apr 2001, Cejka Rudolf wrote: > > > Right now, I have upgraded my -current machine from > > February 13 to April 26. > > > > I were pleased with change to dir allocation in FFS, > > but here are my unpleasant test results (UDMA33, partition > > is 3 GB where 1 GB is free, soft-updates are enabled): > > ... > > rm -r is much faster, but tar xvfz is much slower. > > This is probably caused by write caching now being off by default > in the ata driver, possibly amplified by not using soft updates. > Without the new dir allocation, -current would be even slower :(. > This is also probably caused by write caching not being done. For the people wanting to turn on write caching ... it WILL break the write ordering needed by softupdates and journaling filesystems, so don't do it unless you know what you're doing. I guess it would be better to do this kind of write caching at the kernel level, because the OS has a much better idea of when to write which data to platter than a harddisk can ever have. OTOH, note that switching off write caching on some drive doesn't actually work because the manufacturers would rather do well on some PC mag benchmarks than store your data reliably ... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw: several equal rules under same number bug
On Sat, Apr 28, 2001 at 20:21:36 -0700, Rich Wales wrote: > Andrey A. Chernov wrote: > > > I use equal "ipfw add" several times from the script, but > > the rule number was the same all times. I expect that rule > > is replaced, not added with same number several times. > > No. There can be multiple rules with the same number. If you run > multiple "ipfw add" commands with the same number, they are stored > (and executed) in the order in which they were added. > > Having multiple =identical= rules with the same number doesn't make > too much sense, since -- as you noticed -- the ones after the first > will never match (unless the rule has a "count" action, in which > case all of the identical rules will match). I think it is very contr-intuitive way, better action will be "replace" if number is the same. We have _enough_ numbers to not compact rules in such bad manner. For example "ipfw delete" takes number as an argument, what rule it suppose to delete, if the number is the same? I.e. how can I delete specific rule if all have the same number? Etc, etc. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw: several equal rules under same number bug
>Date: Sun, 29 Apr 2001 08:11:32 +0400 >From: "Andrey A. Chernov" <[EMAIL PROTECTED]> >I think it is very contr-intuitive way, better action will be "replace" if >number is the same. We have _enough_ numbers to not compact rules in such >bad manner. >For example "ipfw delete" takes number as an argument, what rule it >suppose to delete, if the number is the same? I.e. how can I delete >specific rule if all have the same number? Etc, etc. I understand your stated concern, but the proposed "solution" is, to me, worse. I have at least one application where I generate ipfw rules in a script, for a set of subnets which I read from a file at execution time. I am able to use the numbers to group the firewall rules , so that for any given subnet, I can predict the order in which the rules will be applied. But since I don't really know the subnets until the script is running, I would need to make the script far more complicated if we required that each ipfw rule were uniquely numbered. (And since I want to get the ipfw rules in place very early in the boot sequence, additional complication is not exactly what appeals to me.) That said, I (personally) wouldn't have an objection to a mechanism (such as a sysctl) that would determine which of the two ways ipfw would behave, as long as I could retain the current behavior. I wouldn't even mind (again, for myself) if the default were to be changed to be the way you suggest. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: camcontrol stop / restart broken
On Sat, Apr 28, 2001 at 23:09:07 +0300, Tomi Vainio - Sun Finland - wrote: > Hi, > > My source disk is quite noisy so normally I stop it after building the > world and restart it once a week. Couple weeks this restart hasn't > worked as before. Only way to start disk again is reboot. > > camcontrol stop 1:2:0 > Unit stopped successfully > mount /f > mount: /dev/da1s1e: Input/output error > tail /var/log/messages > Apr 28 23:01:40 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack > Apr 28 23:01:40 cat /boot/kernel/kernel: da1: reading primary partition table: error >reading fsbn 0 > camcontrol start 1:2:0 > Unit started successfully > mount /f > mount: /dev/da1s1e: Input/output error Hmm, that's not good. Can you do the following: camcontrol stop da1 camcontrol tur da1 -v [ then you can start it back up with camcontrol start ] What I want to see here is the sense information coming back from the drive when it is spun down. The new error recovery code should be doing the same thing as the old error recovery code -- sending a start unit. For some reason it isn't doing the right thing, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw: several equal rules under same number bug
On Sat, Apr 28, 2001 at 21:22:59 -0700, David Wolfskill wrote: > I have at least one application where I generate ipfw rules in a script, > for a set of subnets which I read from a file at execution time. I am > able to use the numbers to group the firewall rules , so that for any > given subnet, I can predict the order in which the rules will be > applied. In situation you describe you can _add_ rules without any harm, but you can't _delete_ some of them later - it cause totally unpredictable results, i.e. delete operation really not works in the current way. Better way will be to give all subnets unique numbers ranges. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw: several equal rules under same number bug
>Date: Sun, 29 Apr 2001 08:42:20 +0400 >From: "Andrey A. Chernov" <[EMAIL PROTECTED]> >On Sat, Apr 28, 2001 at 21:22:59 -0700, David Wolfskill wrote: >> I have at least one application where I generate ipfw rules in a script, >> for a set of subnets which I read from a file at execution time. I am >> able to use the numbers to group the firewall rules , so that for any >> given subnet, I can predict the order in which the rules will be >> applied. >In situation you describe you can _add_ rules without any harm, but you >can't _delete_ some of them later - it cause totally unpredictable >results, i.e. delete operation really not works in the current way. Better >way will be to give all subnets unique numbers ranges. Well, in that situation, the rules are sufficiently complicated that I'd modify the script or the input list of netmask specifications, and re-run the whole thing. :-} How about a syntax for being able to specify which instantiation of a given ipfw rule number you mean, and a corresponding change to the code to iterate through those instantiations until that one is encountered. (You can probably tell I haven't actually looked at the code) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
