On Thursday 07 June 2007 04:57:42 pm Alexey Dokuchaev wrote:
> On Tue, Sep 05, 2006 at 05:09:42PM +, Alexey Dokuchaev wrote:
> > On Tue, Sep 05, 2006 at 12:25:35PM -0400, John Baldwin wrote:
> > > On Sunday 03 September 2006 14:42, Slawa Olhovchenkov wrote:
> > > > On Tue, Jan 03, 2006 at 09:17
On Tue, Sep 05, 2006 at 05:09:42PM +, Alexey Dokuchaev wrote:
> On Tue, Sep 05, 2006 at 12:25:35PM -0400, John Baldwin wrote:
> > On Sunday 03 September 2006 14:42, Slawa Olhovchenkov wrote:
> > > On Tue, Jan 03, 2006 at 09:17:04AM +, Brian Somers wrote:
> > >
> > > > brian 2006-01-0
Robert,
Your patch works just fine. Please don't forget to MFC it before 6.2 is out.
Thanks!
Regards,
Maxim
Robert Watson wrote:
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
Robert Watson wrote:
The method by which the distinction between ENOSYS+SIGSYS and plain
ENOSYS is determined is in t
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
Robert Watson wrote:
The method by which the distinction between ENOSYS+SIGSYS and plain ENOSYS
is determined is in the implementation of the system call. If a system
call is flagged as unimplemented (i.e., you never hit the function
implementing it
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
Robert Watson wrote:
The method by which the distinction between ENOSYS+SIGSYS and plain ENOSYS
is determined is in the implementation of the system call. If a system
call is flagged as unimplemented (i.e., you never hit the function
implementing it)
Robert Watson wrote:
The method by which the distinction between ENOSYS+SIGSYS and plain
ENOSYS is determined is in the implementation of the system call. If a
system call is flagged as unimplemented (i.e., you never hit the
function implementing it), you get SIGSYS+ENOSYS. If you enter the
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
OK, in this particular case I am trying to run su(8) binary compiled for
FreeBSD/ia32 on FreeBSD/amd64 system (FreeBSD 6.2 but this doesn't really
make any difference since the code is the same).
Since all
Robert Watson wrote:
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
OK, in this particular case I am trying to run su(8) binary compiled
for FreeBSD/ia32 on FreeBSD/amd64 system (FreeBSD 6.2 but this doesn't
really make any difference since the code is the same).
Since all audit syscalls in free
P.S. Perhaps my mistake is that I have blindly assumed that attempt to
invoke unimplemented syscall on native platform (i.e. ia32 binary
running on ia32 kernel) results in the same error condition as attempt
to invoke unimplemented syscall in binary compatibility mode (i.e. ia32
binary on amd64
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
OK, in this particular case I am trying to run su(8) binary compiled for
FreeBSD/ia32 on FreeBSD/amd64 system (FreeBSD 6.2 but this doesn't really
make any difference since the code is the same).
Since all audit syscalls in freebsd32 emulation layer
OK, in this particular case I am trying to run su(8) binary compiled for
FreeBSD/ia32 on FreeBSD/amd64 system (FreeBSD 6.2 but this doesn't
really make any difference since the code is the same).
Since all audit syscalls in freebsd32 emulation layer are redirected to
nosys() any attempt to inv
I am trying to run ia32 su(8) binary on amd64 kernel.
-Maxim
Ruslan Ermilov wrote:
On Tue, Oct 24, 2006 at 08:18:10AM +, Maxim Sobolev wrote:
sobomax 2006-10-24 08:18:10 UTC
FreeBSD src repository
Modified files:
usr.bin/su su.c
Log:
Ignore SIGSYS when BSM is
On Tue, 24 Oct 2006, Maxim Sobolev wrote:
sobomax 2006-10-24 08:18:10 UTC
FreeBSD src repository
Modified files:
usr.bin/su su.c
Log:
Ignore SIGSYS when BSM is compiled in. Otherwise, attempt to invoke su on
system that don't have audit framefork compiled into kernel or
On Tue, Oct 24, 2006 at 08:18:10AM +, Maxim Sobolev wrote:
> sobomax 2006-10-24 08:18:10 UTC
>
> FreeBSD src repository
>
> Modified files:
> usr.bin/su su.c
> Log:
> Ignore SIGSYS when BSM is compiled in. Otherwise, attempt to invoke su on
> system that don't hav
Luoqi Chen <[EMAIL PROTECTED]> writes:
> Log:
> Do not chdir(2) until after setuid(2), otherwise "su - username" would fail
> when root doesn't have the permission to enter target user's home directory.
> If set, PAM environment variable HOME will be used in chdir(2) instead of
> pwd->pw_
On Tue, Sep 05, 2006 at 12:25:35PM -0400, John Baldwin wrote:
> On Sunday 03 September 2006 14:42, Slawa Olhovchenkov wrote:
> > On Tue, Jan 03, 2006 at 09:17:04AM +, Brian Somers wrote:
> >
> > > brian 2006-01-03 09:17:04 UTC
> > >
> > > FreeBSD src repository
> > >
> > > Modified
On Sunday 03 September 2006 14:42, Slawa Olhovchenkov wrote:
> On Tue, Jan 03, 2006 at 09:17:04AM +, Brian Somers wrote:
>
> > brian 2006-01-03 09:17:04 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > usr.bin/su su.c
> > Log:
> > Fix the other su b
On Sun, 3 Sep 2006 22:42:27 +0400 Slawa Olhovchenkov <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 03, 2006 at 09:17:04AM +, Brian Somers wrote:
>
> > brian 2006-01-03 09:17:04 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > usr.bin/su su.c
> > Log:
> >
On Tue, Jan 03, 2006 at 09:17:04AM +, Brian Somers wrote:
> brian 2006-01-03 09:17:04 UTC
>
> FreeBSD src repository
>
> Modified files:
> usr.bin/su su.c
> Log:
> Fix the other su bug reintroduced two commits ago, namely
>
> $ su
> % kill -STOP $$
On Mon, Jan 02, 2006 at 04:27:51AM -0800, Brian Somers wrote:
> > "stop $$/fg" for tcsh is broken now too (cause logout for ssh).
> > (BTW, this test is from commit logs)
> >
> I've looked into this a little... csh blows up quite impressively
> here were (a)sh, bash and zsh work properly. My gues
On Mon, 2 Jan 2006 13:52:58 +0300 Andrey Chernov <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 02, 2006 at 09:46:39AM +, Brian Somers wrote:
> > usr.bin/su su.c
> > Log:
> > Handle the case (that I just broke) where the following hangs:
> >
> > $ su
> > # kill -STOP
Brian Somers <[EMAIL PROTECTED]> writes:
> Log:
> Remove broken code that mucks about with tcsetpgrp() -- even if
> su isn't the foreground process. Hopefully this won't break PAM,
> but I couldn't find any useful information about ache's theory
> that it will.
Thank you. I've given up
On Mon, Jan 02, 2006 at 09:46:39AM +, Brian Somers wrote:
> usr.bin/su su.c
> Log:
> Handle the case (that I just broke) where the following hangs:
>
> $ su
> # kill -STOP $$
You broke not only that.
"stop $$/fg" for tcsh is broken now too (cause logout for ss
Brian Somers wrote:
brian 2006-01-02 08:51:21 UTC
FreeBSD src repository
Modified files:
usr.bin/su su.c
Log:
Remove broken code that mucks about with tcsetpgrp() -- even if
su isn't the foreground process. Hopefully this won't break PAM,
but I couldn't find a
24 matches
Mail list logo