WARNING: this bug present even _before_ my changes, tested with session.c
v1.22
It happens only with 'localhost' and not in remote case. To
reproduce it, call:
ssh localhost
login normally and then exit. At exit you'll see following message on
console (or /var/log/messages):
sshd[]: er
WARNING: this bug appearse even _before_ my changes, I test it with
session.c v1.22
When you log in, locally or remotely, login record not added, logged user
is invisible for 'w' or 'who'. Of course, !use_login assumed. Yes, I have
updated /etc/pam.d
Please fix it.
Perhaps it somehow related
On 2002-04-19 21:00, Chad David wrote:
> I was actually hoping for a few more comments on the code, but thanks
> anyway ;).
Nah... Most of the code looks OK, as far as I can tell. I'm not a C
guru or something similar, but it is fine. Style things like the two
below were what I had written abo
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> When you log in, locally or remotely, login record not added, logged user
> is invisible for 'w' or 'who'. Of course, !use_login assumed. Yes, I have
> updated /etc/pam.d
> Please fix it.
I postd a patch to -current yesterday.
DES
--
Dag-Erlin
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> NOTE: I just commit the fix, see session.c commit log for detailed
> explanation.
Andrey, in the future please *submit patches for review*.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "uns
On Sat, Apr 20, 2002 at 17:12:21 +0200, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > NOTE: I just commit the fix, see session.c commit log for detailed
> > explanation.
>
> Andrey, in the future please *submit patches for review*.
This case is special - that
On Sat, Apr 20, 2002 at 14:39:06 +0400, Andrey A. Chernov wrote:
> WARNING: this bug appearse even _before_ my changes, I test it with
> session.c v1.22
>
> When you log in, locally or remotely, login record not added, logged user
> is invisible for 'w' or 'who'. Of course, !use_login assumed.
This bug still present too. Please handle it somehow, it is clearly comes
from PAM.
On Sat, Apr 20, 2002 at 05:16:35 +0400, Andrey A. Chernov wrote:
> I got this TWO last login lines with recent -current SSH+PAM:
>
> --
> Last login: Sat Apr 20 04:50:45
> from hermes.dia
This one still present, libutil/login.c commit not fix it.
On Sat, Apr 20, 2002 at 14:19:55 +0400, Andrey A. Chernov wrote:
> WARNING: this bug present even _before_ my changes, tested with session.c
> v1.22
>
> It happens only with 'localhost' and not in remote case. To
> reproduce it, call:
>
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> This bug still present too. Please handle it somehow, it is clearly comes
> from PAM.
Andrey, it's quite possible that you're Superman, but I'm not, so GIVE
ME A BREAK. I'm doing this one step at a time. It'll happen much
faster if you stay off
On Sat, Apr 20, 2002 at 18:01:58 +0200, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > This bug still present too. Please handle it somehow, it is clearly comes
> > from PAM.
>
> Andrey, it's quite possible that you're Superman, but I'm not, so GIVE
> ME A BREAK
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> I got this TWO last login lines with recent -current SSH+PAM:
See attached patch.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
//depot/user/des/pam/lib/libpam/modules/pam_lastlog/pam_lastlog.c#9 - /usr/src/lib/libpam/modules/pam_lastlo
On Sat, Apr 20, 2002 at 18:10:50 +0200, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > I got this TWO last login lines with recent -current SSH+PAM:
>
> See attached patch.
It goes better and worse in the same time :-)
Last login: Sat Apr 20 20:16:55 on ttyv4
L
On Sat, Apr 20, 2002 at 20:20:01 +0400, Andrey A. Chernov wrote:
>
> Newlines are gone, but see second line from back 1991 (garbadge on the
> stack of 'last_login_time' variable).
BTW, please notice that printing this line is very conditionalized in
OpenSSH:
options.print_lastlog
command == N
===> usr.bin/enigma
===> usr.bin/env
===> usr.bin/expand
===> usr.bin/false
===> usr.bin/fetch
===> usr.bin/file
===> usr.bin/file2c
===> usr.bin/find
===> usr.bin/finger
===> usr.bin/fmt
===> usr.bin/fold
===> usr.bin/from
===> usr.bin/fstat
In file included from
/.amd_mnt/freefall/host/d/home/d
On Sat, Apr 20, 2002 at 12:02:11AM +0200, John Angelmo wrote:
> Kris Kennaway wrote:
> > On Fri, Apr 19, 2002 at 10:13:23PM +0200, John Angelmo wrote:
> >
> >>After yesterdays new build I found a problem
> >>Xfree86-4 can't start as regular user (exept root)
> >
> >
> > Read the fine message yo
On Fri, Apr 19, 2002 at 08:56:50PM -0700, James Satterfield wrote:
> I've found that wrapper needs to be updated with XFree86-4.
wrapper always needs to be rebuilt when you update X, yes.
Kris
msg37453/pgp0.pgp
Description: PGP signature
Kris Kennaway wrote:
> On Sat, Apr 20, 2002 at 12:02:11AM +0200, John Angelmo wrote:
>
>>Kris Kennaway wrote:
>>
>>>On Fri, Apr 19, 2002 at 10:13:23PM +0200, John Angelmo wrote:
>>>
>>>
After yesterdays new build I found a problem
Xfree86-4 can't start as regular user (exept root)
>>>
>>>
On Sat, Apr 20, 2002 at 10:39:22PM +0200, John Angelmo wrote:
> Well X starts but just to the gray area, no windowmanager starts and the
> error I get(after I have exited) is:
>
> AUDIT: Fri Apr 19 22:09:13 2002: 16472 XFree86: client 1 rejected from
> local host
> AUDIT: Fri Apr 19 22:09:15 20
For the benefit of packet sniffers and other things that only want
read-only access to /dev/bpf*, what do people think of adding a 'bpf'
group for those programs? This allows bpf devices to be read by
programs running with an effective gid of 'bpf' instead of the current
requirement for an effect
On Sat, Apr 20, 2002 at 03:39:14PM -0600, Lyndon Nerenberg wrote:
> For the benefit of packet sniffers and other things that only want
> read-only access to /dev/bpf*, what do people think of adding a 'bpf'
> group for those programs? This allows bpf devices to be read by
> programs running with
> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
Crist> I do this a lot too on systems where it makes sense. But I'm
Crist> not sure I understand what you are asking to be done. Is it
Crist> asking too much of an administrator to do,
There are two ways to handle this. One
On Sat, Apr 20, 2002 at 04:02:13PM -0600, Lyndon Nerenberg wrote:
> > "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
>
> Crist> I do this a lot too on systems where it makes sense. But I'm
> Crist> not sure I understand what you are asking to be done. Is it
> Crist> asking t
Over the past week, I've been trying to get information on how to fix a
server that panics with:
| panic: vm_map_entry_create: kernel resources exhausted
| mp_lock = 0101; cpuid = 1; lapic.id = 0100
| boot() called on cpu#1
Great ... but, how do I determine what 'resources' I need to in
> "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
Crist> OK. Now you've really lost me. What do ports have to do with
Crist> this? Which ports? None of the sniffing programs I am aware
Crist> of use set{g,u}id bits. They rely on the permissions of the
Crist> user running
hello,
this is again about the _thread_kern_pipe issue raised a few days ago.
thinking about it again, it's nonsense to create any pid-specific
workarounds by creating fake stdio. the solution is straightforward;
patch attached (completely untested).
note, that the open() wrapper (and other calls
As a quick follow-up to this, doing more searching on the web, I came
across a few suggested 'sysctl' settings, which I've added to what I had
before, for a total of:
kern.maxfiles=65534
jail.sysvipc_allowed=1
vm.swap_idle_enabled=1
vfs.vmiodirenable=1
kern.ipc.somaxconn=4096
I've also just re
* The Hermit Hacker <[EMAIL PROTECTED]> [020420 16:01] wrote:
>
>
> As a quick follow-up to this, doing more searching on the web, I came
> across a few suggested 'sysctl' settings, which I've added to what I had
> before, for a total of:
>
> kern.maxfiles=65534
> jail.sysvipc_allowed=1
> vm.sw
Yes, I'm in favor of going back to the simple sequence number too.
I don't understand the advantage of the MD5.
While you're in there, could you put back minfree checking too?
That bit me pretty badly today, with savecore filling up my /var
because it doesn't care about minfree.
Bill
To Unsub
On Sat, 20 Apr 2002, Alfred Perlstein wrote:
> * The Hermit Hacker <[EMAIL PROTECTED]> [020420 16:01] wrote:
> >
> >
> > As a quick follow-up to this, doing more searching on the web, I came
> > across a few suggested 'sysctl' settings, which I've added to what I had
> > before, for a total of:
>
"Marc G. Fournier" wrote:
> Over the past week, I've been trying to get information on how to fix a
> server that panics with:
>
> | panic: vm_map_entry_create: kernel resources exhausted
> | mp_lock = 0101; cpuid = 1; lapic.id = 0100
> | boot() called on cpu#1
>
> Great ... but, how do
"Marc G. Fournier" wrote:
> > It'll only work if you set it before your processes setup.
> >
> > Some more information about what these 5000 processes are doing
> > would help.
>
> Sorry ... the server is running ~210 jails ... so the '5k processes' would
> be when they all start up their periodi
On Sat, 20 Apr 2002, Terry Lambert wrote:
> "Marc G. Fournier" wrote:
> > Over the past week, I've been trying to get information on how to fix a
> > server that panics with:
> >
> > | panic: vm_map_entry_create: kernel resources exhausted
> > | mp_lock = 0101; cpuid = 1; lapic.id = 0100
On Sat, Apr 20, 2002 at 04:27:18PM -0600, Lyndon Nerenberg wrote:
> > "Crist" == Crist J Clark <[EMAIL PROTECTED]> writes:
>
> Crist> OK. Now you've really lost me. What do ports have to do with
> Crist> this? Which ports? None of the sniffing programs I am aware
> Crist> of use
Crist J. Clark wrote:
> These are actually very different in that they are set{u,g}id commands
> (well, ps(1) is not set{u,g}id anymore and is root:wheel owned). The
> sniffing tools we've been discussing, and pretty much all of the ones
> I've used, tcpdump(1), snort(8), nmap(1), etc., are not.
On Sun, 21 Apr 2002, Oswald Buddenhagen wrote:
> hello,
>
> this is again about the _thread_kern_pipe issue raised a few days ago.
> thinking about it again, it's nonsense to create any pid-specific
> workarounds by creating fake stdio. the solution is straightforward;
> patch attached (completel
On Sat, 20 Apr 2002, Craig Boston wrote:
> Since -current by default uses devfs, is there a standard way to make the
> ownership/permissions of device nodes "sticky" so that they persist across
> boots?
rc.devfs
--
"We have known freedom's price. We have shown freedom's power.
And in
On Sat, 20 Apr 2002 13:35:32 -0700
Kris Kennaway <[EMAIL PROTECTED]> wrote:
KK> wrapper always needs to be rebuilt when you update X, yes.
All you really need to do is reset the X symlink (unless you are
upgrading from 3 to 4 in which case you need a new wrapper).
--
C:>WIN
38 matches
Mail list logo
