headers
Greywolf | 1 Apr 2005 01:54

Re: "xargs: A: No such file or directory"

[Thus spake Alan Barrett ("AB: ") 3:08pm...]

dM: I wonder if that goal could be better met some other way,

AB:
AB: Sure.  Just add a pkgsrc_bin directory at the front of the PATH, and
AB: populate it with a bunch of symlinks or trivial shell scripts.  But
AB: this seems like a lot of effort for a problem that few people have ever
AB: encountered.
AB:
AB: --apb (Alan Barrett)

You might think that a lot of effort for a corner case, but it might not
be a bad paradigm.  It merits consideration and has the potential to avoid
further problems.  It's probably less fragile to have a front end to build
or refresh such a directory than to depend on envariables which might be
modified by a(n unsuspecting) user...

				--*greywolf;
--
System V was a mistake.
Permalink | Reply | 0 comments |
headers
Simon J. Gerraty | 2 Apr 2005 06:35

Re: sh & IFS

>> >Incidently, at this point, what's left in ksh that isn't in /bin/sh?
>> 
>> In 2.0 anyway, emacs mode bindings for [pd]ksh's 
>> 
>> \e\e	complete word
>> \e=	list possible completions
>> \e.	yank last word from previous line
>
>Fix libedit....  I only use the 'vi' style editing - which I fixed.

I fixed all that in pdksh (emacs mode) - many years ago when I was the
maintainer.

>> cd -2 or cd -mk would take me to /g/sjg/work/sjg/mk
>
>Eh? what has that got to do with arrays?

/etc/ksh.cdhist is implemented using arrays

>In any case the ksh arrays aren't in posix, and are unlikely to be
>implemented - they are just plain broken.

Then I'll stick with ksh - cdhist is the only reason I ever saw for
supporting arrays though ;-) though I generally avoid writing ksh
specific scripts.

>sh also doesn't keep a cd history, nor even a persistent (or shared)

ksh doesn't keep cd history by default either, my /etc/ksh.kshrc
includes ksh.cdhist though and it blows to do without.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rui Paulo | 2 Apr 2005 18:59

Re: standards/25825


I've ported strfmon() from FreeBSD and added some changes to comply with
NetBSD userland and CVS repository.

It's available from:
        http://www.netbsd-pt.org/users/rpaulo/netbsd/strfmon-netbsd-20050401.gz
        (the first parte is a unified diff and the rest is a shar)

As you might know, strfmon() is part of IEEE Std 1003.1-2001, so I guess this
is useful enough to have in NetBSD.

What do you think ? 

--

-- 
 Rui Paulo <rpaulo <at> netbsd-pt.org>        http://www.netbsd-pt.org/users/rpaulo/
Permalink | Reply | 0 comments |
headers
Geert Hendrickx | 5 Apr 2005 18:01
Picon

protection against login trojans?

Hi, 

I was wondering whether it is possible for a user to protect himself
against login trojans.  Another user could easily write a shell script
that displays a login: prompt, followed by a Password: prompt, and then
leave the console.  The next user would then enter his login-name and
password into that trojan.  

In XDM you could simply hit Ctrl-Alt-Backspace to reset the X-server.
In win2k you can hit Ctrl-Alt-Delete, also to reset the login-prompt.  

Is there any way to reset a UNIX getty (or could that be implemented?), 
so that a user can be sure he's talking to getty and not to some trojan?  

Thanks, 

GH

PS: please CC me.  

--

-- 
:wq
Permalink | Reply | 4 comments |
headers
Jim Wise | 6 Apr 2005 17:20
Gravatar

Re: CVS commit: src/etc


On Tue, 5 Apr 2005, Peter Postma wrote:

>
>Module Name:	src
>Committed By:	peter
>Date:		Tue Apr  5 19:57:30 UTC 2005
>
>Modified Files:
>	src/etc: group postinstall
>
>Log Message:
>Add _pflogd group.

Is there any reason this group cannot be simply `pflogd'?  We don't have 
any other groups with _ in their name...

More generally, what does _pflogd have access to that prevents it from 
being subsumed into, e.g. `daemon'?

--

-- 
				Jim Wise
				jwise <at> draga.com
Permalink | Reply | 0 comments |
headers
Jim Wise | 6 Apr 2005 17:29
Gravatar

Re: protection against login trojans?


On Tue, 5 Apr 2005, Geert Hendrickx wrote:

>Hi, 
>
>I was wondering whether it is possible for a user to protect himself
>against login trojans.  Another user could easily write a shell script
>that displays a login: prompt, followed by a Password: prompt, and then
>leave the console.  The next user would then enter his login-name and
>password into that trojan.  
>
>In XDM you could simply hit Ctrl-Alt-Backspace to reset the X-server.
>In win2k you can hit Ctrl-Alt-Delete, also to reset the login-prompt.  
>
>Is there any way to reset a UNIX getty (or could that be implemented?), 
>so that a user can be sure he's talking to getty and not to some trojan?  

Traditionally, many Unixes have supported a `secure login path' 
extension, which would, upon receiving a `break' character on a terminal 
line, kill the processes using that terminal -- in the case where getty 
was running, this would simply result in getty being respawned, and in 
the case where a trojan was running, this would kill it, also resulting 
in getty being respawned.

I don't know that NetBSD supports this, but if not, it would be worth 
implementing...

--

-- 
				Jim Wise
				jwise <at> draga.com
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hubert Feyrer | 6 Apr 2005 18:05
Picon
Favicon

Re: protection against login trojans?

On Wed, 6 Apr 2005, Jim Wise wrote:
> I don't know that NetBSD supports this, but if not, it would be worth
> implementing...

Ctl-Alt-Esc
r

;-)

Sounds useful to notify a (virtual) console to receive a break/hangup and 
then restart whatever is running there...

  - Hubert

--

-- 
NetBSD - Free AND Open!      (And of course secure, portable, yadda yadda)
Permalink | Reply | 1 comment |
headers
Jim Wise | 6 Apr 2005 18:37
Gravatar

Re: CVS commit: src/etc


On Wed, 6 Apr 2005, Peter Postma wrote:

>On Wed, Apr 06, 2005 at 11:20:58AM -0400, Jim Wise wrote:
>> >Log Message:
>> >Add _pflogd group.
>> 
>> Is there any reason this group cannot be simply `pflogd'?  We don't have 
>> any other groups with _ in their name...
>> 
>
>The idea is to prefix new system-users/groups with an _, so that they are
>in their own namespace.

Really?  Whose idea?  Where was this discussed?  What other groups have 
we ever introduced this way?

Please change this group name to pflogd.

>>> More generally, what does _pflogd have access to that prevents it from 
>> being subsumed into, e.g. `daemon'?
>>
>
>None. If pflogd(8) gets compromised then no-one can do anything with it
>because _pflogd has no special privileges and no other program is using the
>user/group. daemon, however, is used by other programs, so when one of
>them gets compromised, the others might be easy/easier to compromise too.
>
>This maybe sounds like OpenBSD paranoia, but I think it's reasonable to
>follow this.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Postma | 6 Apr 2005 18:33
Picon

Re: CVS commit: src/etc

On Wed, Apr 06, 2005 at 11:20:58AM -0400, Jim Wise wrote:
> >Log Message:
> >Add _pflogd group.
> 
> Is there any reason this group cannot be simply `pflogd'?  We don't have 
> any other groups with _ in their name...
> 

The idea is to prefix new system-users/groups with an _, so that they are
in their own namespace.

> More generally, what does _pflogd have access to that prevents it from 
> being subsumed into, e.g. `daemon'?
>

None. If pflogd(8) gets compromised then no-one can do anything with it
because _pflogd has no special privileges and no other program is using the
user/group. daemon, however, is used by other programs, so when one of
them gets compromised, the others might be easy/easier to compromise too.

This maybe sounds like OpenBSD paranoia, but I think it's reasonable to
follow this.

--

-- 
Peter Postma
Permalink | Reply | 1 comment |
headers
Peter Postma | 6 Apr 2005 19:06
Picon

Re: CVS commit: src/etc

On Wed, Apr 06, 2005 at 12:37:52PM -0400, Jim Wise wrote:
> On Wed, 6 Apr 2005, Peter Postma wrote:
> >The idea is to prefix new system-users/groups with an _, so that they are
> >in their own namespace.
> 
> Really?  Whose idea?  Where was this discussed?  What other groups have 
> we ever introduced this way?
> 
> Please change this group name to pflogd.
> 

It was discussed for the _pflogd user somewhere in september 2004 and I got
approval from core to add the user and group. I'd rather not rename it
because then we will be incompatible with FreeBSD/OpenBSD.

> >>> More generally, what does _pflogd have access to that prevents it from 
> >> being subsumed into, e.g. `daemon'?
> >>
> >
> >None. If pflogd(8) gets compromised then no-one can do anything with it
> >because _pflogd has no special privileges and no other program is using the
> >user/group. daemon, however, is used by other programs, so when one of
> >them gets compromised, the others might be easy/easier to compromise too.
> >
> >This maybe sounds like OpenBSD paranoia, but I think it's reasonable to
> >follow this.
> 
> If the goal is to ensure that someone who compromises pflogd does not 
> get access to useful services, it should run as nobody or as daemon.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane