Re: netstart false positive Warning
On 2010/11/06 18:49, Bahador NazariFard wrote: > > Thank you for your very soon reply > Excuse me you are right. > I had installed gnuls-4.1p2 (colorized GNU 'ls') and I had defined > alias ls='gls --color=tty'. > unfortunately it seems gls -n does not work properly and it was the > reason of that problem. The system scripts assume a clean shell environment, we can't really protect against an unclean shell - somebody may have made an alias for ifconfig, chmod, chown, or even /bin/ls (yes this is possible!). I think you're probably using '. /etc/netstart ...' which runs the script in the current shell; instead use 'sh /etc/netstart ...' which will solve this (and other possible problems). > However I do not agree with you that ls -nl is pointless and ambiguous. > If we read ls manual, we can find these lines about -n option. > -n List in long format as in -l, but retain user and group IDs in > a > numeric format. The output of -gn and -ng is identical: a > long > listing with numerical group ID, and no numerical user > ID. The > output of -ln and -nl is identical: a long listing with > numerical > group and user ID. > therefore there is no problem and we can use ls -nl . Ah, then I agree that it's not ambiguous, though I still think it's pointless to use -nl when -n does the same.
Re: netstart false positive Warning
On Sat, 6 Nov 2010, Hendrickson, Kenneth wrote: > Many versions ago, I broke my OpenBSD box by defining aliases for ls(1). > Specifically, I broke make(1). I couldn't build the kernel nor > userland. That was fixed years ago when the shell was corrected to--in accordance with POSIX--not parse any rcfiles unless it's either interactive or a login shell. At this point, the issue is running with a PATH that overrides programs that the scripts or build uses and that don't match OpenBSD's expectations. > It is probably a good idea not to use aliases for ls(1) in OpenBSD, when > you are doing system stuff. Aliases and shell functions are no longer an issue. > From: owner-b...@openbsd.org on behalf of Bahador NazariFard > Subject: Re: netstart false positive Warning ... > I had installed gnuls-4.1p2 (colorized GNU 'ls') and I had defined > alias*ls='gls --color=tty' > *. > unfortunately it seems *gls -n* does not work properly and it was the reason > of that problem. The OpenBSD build and system scripts may require various OpenBSD-specific extensions, so even a POSIX compliant version of a utility may break things if installed under the same name. This gnuls doesn't even comply with POSIX on the behavior of -n and -L, so I wouldn't be surprised if it broke even portable scripts. So, when installing such programs, don't install them under a name that conflicts with the OpenBSD version: install them under some other name and then use aliases for interactive use. Philip Guenther
Re: netstart false positive Warning
Many versions ago, I broke my OpenBSD box by defining aliases for ls(1). Specifically, I broke make(1). I couldn't build the kernel nor userland. It is probably a good idea not to use aliases for ls(1) in OpenBSD, when you are doing system stuff. Ken Hendrickson PS I no longer have the exact ls(1) alias which broke make(1). -Original Message- From: owner-b...@openbsd.org on behalf of Bahador NazariFard Sent: Sat 11/6/2010 10:00 AM To: Bahador NazariFard; bugs@openbsd.org Subject: Re: netstart false positive Warning On Sat, Nov 6, 2010 at 3:15 PM, Stuart Henderson wrote: > On 2010/11/06 14:12, Bahador NazariFard wrote: > > Hi > > > > I am using OpenBSD operating system. > > > > I think there is a problem in* /etc/netstart* on Line 44: *set -A stat -- > > `ls -nL $file`* > > I think we should change this line to *set -A stat -- `ls -nl $file`* > > > > Before fixing this problems always netstart prints "*WARNING: $file is > > insecure, fixing permissions*" > > netstart deliberately only looks at the target of a symlink for > these files (both when we check and when we chmod/chown. > ls -nl is pointless and ambiguous, -n means "long output with > numeric values for uid/gid" and -l means "long output with > names for uid/gid". > > What are the permissions on your /etc/hostname.* files? > Are you doing anything strange with flags? > (check with ls -lo or something). > > Thank you for your very soon reply Excuse me you are right. I had installed gnuls-4.1p2 (colorized GNU 'ls') and I had defined alias*ls='gls --color=tty' *. unfortunately it seems *gls -n* does not work properly and it was the reason of that problem. thank you again for your response best regards,
Re: netstart false positive Warning
On Sat, Nov 6, 2010 at 3:15 PM, Stuart Henderson wrote: > On 2010/11/06 14:12, Bahador NazariFard wrote: > > Hi > > > > I am using OpenBSD operating system. > > > > I think there is a problem in* /etc/netstart* on Line 44: *set -A stat -- > > `ls -nL $file`* > > I think we should change this line to *set -A stat -- `ls -nl $file`* > > > > Before fixing this problems always netstart prints "*WARNING: $file is > > insecure, fixing permissions*" > > netstart deliberately only looks at the target of a symlink for > these files (both when we check and when we chmod/chown. > ls -nl is pointless and ambiguous, -n means "long output with > numeric values for uid/gid" and -l means "long output with > names for uid/gid". > > What are the permissions on your /etc/hostname.* files? > Are you doing anything strange with flags? > (check with ls -lo or something). > > Thank you for your very soon reply Excuse me you are right. I had installed gnuls-4.1p2 (colorized GNU 'ls') and I had defined alias*ls='gls --color=tty' *. unfortunately it seems *gls -n* does not work properly and it was the reason of that problem. thank you again for your response best regards,
Re: netstart false positive Warning
On 2010/11/06 14:12, Bahador NazariFard wrote: > Hi > > I am using OpenBSD operating system. > > I think there is a problem in* /etc/netstart* on Line 44: *set -A stat -- > `ls -nL $file`* > I think we should change this line to *set -A stat -- `ls -nl $file`* > > Before fixing this problems always netstart prints "*WARNING: $file is > insecure, fixing permissions*" netstart deliberately only looks at the target of a symlink for these files (both when we check and when we chmod/chown. ls -nl is pointless and ambiguous, -n means "long output with numeric values for uid/gid" and -l means "long output with names for uid/gid". What are the permissions on your /etc/hostname.* files? Are you doing anything strange with flags? (check with ls -lo or something).
