Re: syslog(3) issues
Attilio, good day. Mon, Sep 03, 2012 at 12:35:24AM +0100, Attilio Rao wrote: > I was trying to use syslog(3) in a port application that uses > threading , having all of them at the LOG_CRIT level. What I see is > that when the logging gets massive (1000 entries) I cannot find some > items within the /var/log/messages (I know because I started stamping > also some sort of message ID in order to see what is going on). The > missing items are in the order of 25% of what really be there. > > Someone has a good idea on where I can start verifying for my syslogd > system? This is almost obvious, but had you tried running syslogd with flag '-d' that gives verbose information about incoming stuff and whether it will be logged to some file(s). -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpRJcsuJ1Dg3.pgp Description: PGP signature
Re: src builds and STDERR
Thu, Mar 01, 2012 at 09:38:06AM -0800, Garrett Cooper wrote: > On Thu, Mar 1, 2012 at 9:01 AM, Chris Rees wrote: > > On 1 Mar 2012 16:31, "Garrett Cooper" wrote: > >> See: > >> http://lists.freebsd.org/pipermail/freebsd-current/2011-December/029852.html > >> . Why this patch is still not in FreeBSD proper, I do not know. [...] > bin/165589 -- thanks! The patch from mailing list was already committed to HEAD more than 2 weeks ago, http://svnweb.freebsd.org/base?view=revision&revision=231544 Don't see the MFC timeline, though. Max, any plans for MFC? On the other hand, the error diagnostics from make goes to stdout -- not very good, because more logical place is stderr. The following patch should help a bit, http://codelabs.ru/fbsd/patches/make/make-redirect-own-error-messages-to-stderr.patch but I should review it once more and modify the regression suite to handle the change in the make behaviour. Any thoughts? -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpm0Pfc8k2x6.pgp Description: PGP signature
Re: [sudo] configure --host=i386
Sean, good day. Tue, Feb 28, 2012 at 11:00:19AM -0800, Sean Bruno wrote: > I was trying to cross compile sudo for i386 on an amd64 host and was > befuddled by the following ./configure error output. > > checking for library containing crypt... -lcrypt > checking for library containing getspnam... no > checking for library containing getprpwnam... no > configure: error: "dlopen present but libtool doesn't appear to support > your platform." What were the commands for cross-compilation? Was it done using the ports tree or just the official tarball? -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpZX3dAiui7i.pgp Description: PGP signature
Re: Blackhole routes vs firewall drop rules
Sun, Feb 26, 2012 at 01:34:23PM +, Bob Bishop wrote: > I'd like to hear from somebody who understands this stuff on the > relative merits of blackhole routes vs firewall drop rules for > dealing with packets from unwanted sources. I'm particularly > interested in efficiency and scalability. Thanks Are you trying to null-route (seems like its what you call blackhole routes) or firewall on the same machine that is the destination of the packets, on the same machine that is an intermediate router or you're evaluating the null-routing on the intermediate machine vs firewall on the target machine? By the way, with null-routing you'll be able only to blackhole the packets that are going only _to_ some particular IP address or netblock. Routing is almost entirely about the destination IPs (though in some cases you can differentiate on the incoming interface or you can use URPF, if it is supported by your device, but that's not the routing in the strict sense, nevertheless, many routing devices have something that looks like URPF). For FreeBSD the closest analog of URPF is ipfw's verrevpath and pf's urpf-failed. You can do source-based null-routing by injecting null route to the unwanted source, so the packet will be dropped. The neat thing here is that you can use some routing protocol to distribute your blackhole routes to multiple FreeBSD servers and ipfw/pf will do the rest. But if you can sync the blackholing firewall tables (both ipfw and pf support tables that can be updated independently of the firewall rules) across multiple hosts (if you're going to do the distributed blackholing) without handing this work to the routing protocols, this might be faster -- you'll save routing table lookup (though the firewall should inspect the source address, but that should be slightly quicker than to do routing table lookup). At the large scale, null routing nowadays is mostly used for tearing down distributed DDoS. You, probably want to read this thread on NANOG list, http://www.gossamer-threads.com/lists/nanog/users/138153 The typical usage is that some IP or netblock that are under the attack are null-routed on the provider's edges (if the provider hosts this IP/netblock) and internal leafs to tear down the packets before they can flood the infrastructure. If multiple providers (better if they contain the sources for the attack) can do that, the attacking traffic won't even exit their networks and that's a good thing when you're fighting DDoS. But, in general, it will be much better to know your situation to answer such question in a more appropriate manner. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpH9u5suDC7Y.pgp Description: PGP signature
Re: Alternate source trees
Tue, Aug 16, 2011 at 01:09:32PM +0100, Matt Burke wrote:
> How does the build process know about the non-symlinked path anyway?
> I can't see where (or understand why) it uses "pwd -P"
Make(1)'s .OBJDIR is used:
{{{
.OBJDIR A path to the directory where the targets are built. At
startup, make searches for an alternate directory to
place target files. It will attempt to change into this
special directory and will search this directory for
makefiles not found in the current directory. The fol-
lowing directories are tried in order:
1. ${MAKEOBJDIRPREFIX}/`pwd`
2. ${MAKEOBJDIR}
3. obj.${MACHINE}
4. obj
5. /usr/obj/`pwd`
The first directory that make successfully changes into
is used. If either MAKEOBJDIRPREFIX or MAKEOBJDIR is set
in the environment but make is unable to change into the
corresponding directory, then the current directory is
used without checking the remainder of the list. If they
are undefined and make is unable to change into any of
the remaining three directories, then the current direc-
tory is used. Note, that MAKEOBJDIRPREFIX and MAKEOBJDIR
must be environment variables and should not be set on
make's command line.
The make utility sets .OBJDIR to the canonical path given
by getcwd(3).
}}}
getcwd(3) always fully resolves current path, so symlinking
won't be taken into account.
> I'm trying to setup a box to do automated FreeBSD builds for other hosts
> from multiple source trees.
>
> I have a couple of source trees mounted - for legibility's sake let's say
> /build/stable and /build/current. I also have a few obj dirs for different
> targets. The current obj tree is symlinked to /usr/obj, and this works fine.
>
> The problem comes when I symlink /usr/src: when I buildworld, I get
> /usr/obj/build/current/[...] instead of the desired /usr/obj/usr/src/[...]
> This is presumably fine when installing on the same machine, but it breaks
> when using it on another host with /usr/src and /usr/obj mounted over nfs.
Hmm, current Makefile system for src sets MAKEOBJDIRPREFIX via ?=, so
you're out of luck with symlinking on the build machine. May be you
can mount /build/stable or /build/current on the target machine via
NFS (and, of course, /usr/obj or other directory that you can choose
with the MAKEOBJPREFIX, this leaves room for multi-architecture object
trees on the same build host) and invoke make from the relevant
directory?
Another possibility, if for some reason you want /usr/src to point to
the correct place at your "destination" machines, to always mount
/build across hosts where you're installing the stuff and to symlink
/usr/src to the proper location inside the /build.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgp1Ikwq7VChK.pgp
Description: PGP signature
Re: cam / ata timeout limited to 2147 due to overflow bug?
Fri, Aug 05, 2011 at 10:59:43AM +0100, Steven Hartland wrote: > I've tried the patch and it a few cut and paste errors, which I've fixed, Thanks for spotting that! > and confirmed it works as expected, so thanks for that :) > > There's also a load more drivers with the same issue so I've gone through > and fixed all the occurances I can find. Here's the updated patch:- > http://blog.multiplay.co.uk/dropzone/freebsd/ccb_timeout.patch I had found a couple of missed drivers, fixed overlong lines and fixed the missing 10 in the sys/dev/hptrr/hptrr_os_bsd.c. Also changed ciss to have u_int32_t timeouts instead of int ones: this should not harm anything, because all passed timeouts are explicit numbers that are not larger than 10. And I had also renamed CAM_HDR_TIMEOUT_TO_TICKS to the base CAM_TIMEOUT_TO_TICKS, because it seems that every CAM timeout is 32-bit long. The new patch lives at http://codelabs.ru/fbsd/patches/cam/CAM-properly-convert-timeout-to-ticks.diff But there are some cases where the argument to the CAM_TIMEOUT_TO_TICKS is int and not u_int32_t. It should be mostly harmless for now, since the values do not exceed 2^32, but my current feeling about timeouts that are counted in milliseconds that there should be an in-kernel type for this stuff. Seems like 32-bit wide unsigned value is good for it: maximal value is around 46 days that should be fine for the millisecond-precision timeout. Through my grep session for the kernel sources I had seen other (t * hz / 1000) constructs, so I feel that the fix should be extended to cover these cases as well. I am interested in the other's opinions on this. Thanks again! -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpHUczlg0J1x.pgp Description: PGP signature
Re: cam / ata timeout limited to 2147 due to overflow bug?
Steven, good day.
Fri, Aug 05, 2011 at 12:02:19AM +0100, Steven Hartland wrote:
> So I suspect that this is what's happening resulting in an extremely
> small timeout instead of a large one. Now I know that passed in value
> to the timeout is seconds * 1000 so we should be seeing 2148000
> for ccb->ccb_h.timeout now multiply that by 1000 (hz) and your over
> the int wrap point 2147483647.
>
> So instead of the wrap point being 2147483 seconds (24 days), I suspect
> because of the way this is structured its actually 2147 seconds (26mins).
>
> If this is the case the fix is likely to be something like:-
> callout_reset(&slot->timeout, (int)(ccb->ccb_h.timeout * (hz / 2000)),
It will give you 0 timeout for all values of hz that are lower than
2000: hz is int, so you'll get integer division. Since ccb_h.timeout
is u_int32_t, the proper way to handle this situation would be
{{{
(u_int64_t)ccb->ccb_h.timeout * (u_int32_t)hz)/2000
}}}
as long as the value of hz won't be greater than 2^32.
Can you try the patch at
http://codelabs.ru/fbsd/patches/ahci/AHCI-properly-convert-CAM-timeout-to-ticks.diff
> What I don't understand is why the /2000
It gives (timeout_in_ticks)/2. The code in ahci_timeout does the following:
{{{
/* Check if slot was not being executed last time we checked. */
if (slot->state < AHCI_SLOT_EXECUTING) {
/* Check if slot started executing. */
sstatus = ATA_INL(ch->r_mem, AHCI_P_SACT);
ccs = (ATA_INL(ch->r_mem, AHCI_P_CMD) & AHCI_P_CMD_CCS_MASK)
>> AHCI_P_CMD_CCS_SHIFT;
if ((sstatus & (1 << slot->slot)) != 0 || ccs == slot->slot ||
ch->fbs_enabled)
slot->state = AHCI_SLOT_EXECUTING;
callout_reset(&slot->timeout,
(int)slot->ccb->ccb_h.timeout * hz / 2000,
(timeout_t*)ahci_timeout, slot);
return;
}
}}}
So, my theory is that the first half of the timeout time is devoted
to the transition from AHCI_SLOT_RUNNING -> AHCI_SLOT_EXECUTING and
the second one is the transition from AHCI_SLOT_RUNNING -> TIMEOUT
to give the whole process the duration of a full timeout. However,
judging by the code, if the slot won't start executing at the first
invocation of ahci_timeout that was spawned by the callout armed in
ahci_execute_transaction, we can have timeouts more than for the
specified amount of time. And if the slot will never start its
execution, the callout will spin forever, unless I am missing something
important here.
May be Alexander can shed some light into this?
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpECHSLq9JWo.pgp
Description: PGP signature
Re: freeBSD8.2: getgrgid() works only for wheel group.
Rekhesh, good day. Wed, Aug 03, 2011 at 06:26:13PM +0530, Rekhesh Mohan wrote: > I'm trying to install mailman on a freeBSD 8.2 box. Mailman allows only > the apache-www group to run its CGI scripts and only the mail group can > execute some of the mailing list related functionalities. Mailman is > using getgrgid() to check the group name. This is failing on me. > > It appears that only the wheel group members are allowed to use > getgrgid() on my machine. getgrgid() returns (null) for others. I was > wondering if anyone else has faced this situation. What's the output from 'ls -l /etc/group; ls -ld /etc'? -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpGINgzY3qL2.pgp Description: PGP signature
Re: broadcast oddity
Wed, Jul 20, 2011 at 12:34:38PM +0300, Daniel Braniss wrote:
> from the diskless:
> els-01# ifconfig
> vr0: flags=8843 metric 0 mtu 1500
> options=8280b
> ether 00:0d:b9:22:57:18
> inet 132.65.91.1 netmask 0xf000 broadcast 132.65.95.255
> media: Ethernet autoselect (100baseTX )
> status: active
> lo0: flags=8049 metric 0 mtu 16384
> options=3
> inet 127.0.0.1 netmask 0xff00
> els-01# netstat -rn
> Routing tables
>
> Internet:
> DestinationGatewayFlagsRefs Use Netif Expire
> default132.65.80.1UG 016606vr0
> 127.0.0.1 link#4 UH 0 36lo0
> 132.65.80.0/20 link#1 U 086612vr0
> 132.65.91.1link#1 UHS 0 12lo0
>
> from the non-diskless:
> wrap-1# ifconfig
> sis0: flags=8943 metric 0 mtu
> 1500
> options=83808
> ether 00:0d:b9:00:72:a8
> inet 132.65.80.181 netmask 0xf000 broadcast 132.65.95.255
> media: Ethernet autoselect (100baseTX )
> status: active
> sis1: flags=8802 metric 0 mtu 1500
> options=83808
> ether 00:0d:b9:00:72:a9
> media: Ethernet autoselect (none)
> status: no carrier
> lo0: flags=8049 metric 0 mtu 16384
> options=3
> inet 127.0.0.1 netmask 0xff00
>
> wrap-1# netstat -rn
> Routing tables
>
> Internet:
> DestinationGatewayFlagsRefs Use Netif Expire
> default132.65.80.1UGS 016936 sis0
> 127.0.0.1 link#4 UH 0 76lo0
> 132.65.80.0/20 link#1 U 067433 sis0
> 132.65.80.181 link#1 UHS 00lo0
The only difference I see is the absence of the 'S' flag on the default
route for the diskless case. Will try to create the testbed.
> > Yes, it is. But ip_output.c has the following code,
> > {{{
> > if (rte->rt_flags & RTF_GATEWAY)
> > dst =3D (struct sockaddr_in *)rte->rt_gateway;
> > if (rte->rt_flags & RTF_HOST)
> > isbroadcast =3D (rte->rt_flags & RTF_BROADCAST);
> > else
> > isbroadcast =3D in_broadcast(dst->sin_addr, ifp);
> > }}}
> >
> > So, if the route that is selected is the gateway, then there will be
> > no broadcast on the L2. At least in my understanding of the code.
> > Thus, I am interested in the routing tables and route flags.
>
> so it boils down to a problem in selecting the route?
More-or-less so: for default gateways there will never be any
L2-broadcasts, for host routes the L2-broadcasts are governed by the
'B' route flag and for other routes the destination address governs
the behaviour (INADDR_ANY & INADDR_BROADCAST as the destination will
enable L2-broadcast unconditionally /but most likely we will hit the
default route earlier for this case/, interface broadcast address
/132.65.95.255 in your case/ will enable L2-brodcast via the
corresponding interface).
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpK7Keb4pSsT.pgp
Description: PGP signature
Re: broadcast oddity
Tue, Jul 19, 2011 at 10:40:11AM +0300, Daniel Braniss wrote:
> > And that non-broadcast ethernet address is the MAC of your
> > default router?
> yes.
Fine, that is more-or-less expected, since the network subsystem
just routes 255.255.255.255 to the default gateway. The issue
you're seeing were already seen before,
http://lists.freebsd.org/pipermail/freebsd-net/2005-October/008626.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=72468
http://lists.freebsd.org/pipermail/freebsd-net/2007-January/012874.html [1]
and bms@ told me that in this case the default gateway routing is the
correct historical behaviour of FreeBSD.
[1] I finally remembered that I had seen this issue too ;))
> > What's your routing table (netstat -rn) for the PXE-booted host?
>
> it's ok, same in both cases. it's picked up via DHCP, in the diskless
> case by the boot/loader in the second via dhcpclient.
Still, can you show both of them?
> > You nailed it: you should send packets to the network's broadcast,
> > not to the 0x.
> >
> but I'm at the user/ip level!, have no way to set mac/ethernet address.
I meant the IP's network broadcast and by 0x I meant
255.255.255.255. Please, look at the posted code.
> still, the question is why it works in one case, and failes in the other.
Yes, it is. But ip_output.c has the following code,
{{{
if (rte->rt_flags & RTF_GATEWAY)
dst = (struct sockaddr_in *)rte->rt_gateway;
if (rte->rt_flags & RTF_HOST)
isbroadcast = (rte->rt_flags & RTF_BROADCAST);
else
isbroadcast = in_broadcast(dst->sin_addr, ifp);
}}}
So, if the route that is selected is the gateway, then there will be
no broadcast on the L2. At least in my understanding of the code.
Thus, I am interested in the routing tables and route flags.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgp5BH7fvJOj1.pgp
Description: PGP signature
Re: broadcast oddity
Daniel, good day.
Mon, Jul 18, 2011 at 05:04:27PM +0300, Daniel Braniss wrote:
> this code behaves correctly when run from a diskless host which
> booted via PXE, but fails on a host that was booted from disk.
> hint: the non working sends a packet with a non ethernet broadcast
> address and an ip address of 255.255.255.255,
And that non-broadcast ethernet address is the MAC of your
default router?
> the working version sets the ethernet address to 0x and the
> ip to the network broadcast address.
What's your routing table (netstat -rn) for the PXE-booted host?
> what am I doing wrong?
>
> danny
> PS: what is the correct way to obtain the network broadcast address?
You nailed it: you should send packets to the network's broadcast,
not to the 0x.
And in order to find the broadcast address for the interface (or
network at that interface), you should use getifaddrs(), like in the
attached example. It is very quick and dirty one and it has some
limitations (e.g., it takes the first broadcast address from the
interface), but it should be a good starting point.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
#include
#include
#include
#include
#include
#include
#include
#include
#include
void
bcast(in_addr_t addr)
{
int so, on;
char msg[BUFSIZ];
struct timespec t2;
struct sockaddr_in soin;
if((so = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) {
perror("socket");
exit(-1);
}
on = 1;
if(setsockopt(so, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) {
perror("setsockopt");
exit(-1);
}
bzero(&soin, sizeof(struct sockaddr_in));
soin.sin_len = sizeof(struct sockaddr_in);
soin.sin_family = AF_INET;
soin.sin_addr.s_addr = addr;
soin.sin_port = htons(12345);
while(1) {
clock_gettime(CLOCK_REALTIME, &t2);
sprintf(msg, "0x%016x", t2.tv_sec);
if(sendto(so, msg, strlen(msg)+1,
0, (struct sockaddr *)&soin, sizeof(struct sockaddr)) < 0) {
perror("sendto");
break;
}
sleep(10);
}
}
main(int argc, char *argv[])
{
struct ifaddrs *ifap, *ifa, *our_if;
struct sockaddr_in *sin;
if (argc < 2)
errx(1, "No arguments");
if (getifaddrs(&ifap) != 0)
perror("getifaddrs");
our_if = NULL;
for (ifa = ifap; ifa != NULL; ifa = ifa->ifa_next) {
if (strcmp(argv[1], ifa->ifa_name) == 0) {
sin = (struct sockaddr_in *)ifa->ifa_broadaddr;
if (!(ifa->ifa_flags & IFF_BROADCAST) ||
sin == NULL ||
sin->sin_addr.s_addr == 0)
continue;
our_if = ifa;
break;
}
}
if (!our_if)
errx(1, "Can't find broadcast-able interface '%s'", argv[1]);
bcast(sin->sin_addr.s_addr);
freeifaddrs(ifap);
}
pgpTxeHVn6MHm.pgp
Description: PGP signature
Re: Mem leak : malloc/free + pthreads = leakage?
Fri, Mar 04, 2011 at 10:02:45PM -0600, Eric Anderson wrote: > I have a moderately threaded userland program (all C) I am working > on (using pthreads, freebsd 8.1 64bit). It seems to leak memory > (using standard malloc/free) badly. I am using pcap to capture > packets and process them. I have a handful of libs statically linked > in (pcap is one, the rest don't seem to matter - I can remove them > and still see the leak). > > Does anyone know of issues regarding malloc/free on multithreaded > userland apps? I personally hadn't heard about them, but you can definitely run your program under Valgrind's memcheck tool -- it often does the good amount of work and detects many leaks. Valrgind is ported to FreeBSD, devel/valgrind. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpOEzCdUHTI2.pgp Description: PGP signature
Re: insufficient flag handling in tools/install.sh
Alexander, good day. Fri, Feb 04, 2011 at 10:22:21AM +, Alexander Best wrote: > hi eygene. thanks a lot for your patch. You're welcome ;)) > i made two changes: > > 1) also catch the -v option for install(1). Yep. > 2) install(1) accepts multiple directories as arguments, when he -d flag has >been specified. so i don't think it's necessary to iterate through all the >directories passed to install.sh and invoke install(1) with only one >argument at a time. I had overlooked that, thanks for spotting. > could you take a look at the attached patch? Looks fine and works for me, thanks! -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpuyRGeAXEha.pgp Description: PGP signature
Re: insufficient flag handling in tools/install.sh
Alexander, good day.
Thu, Feb 03, 2011 at 07:43:06PM +, Alexander Best wrote:
> it seems the -d flag breaks the semantics of tools/install.sh entirely and
> using the script in such a case simply passes all args over to install(1).
>
> simply adding the -d flag to the first switch statement won't work, since we
> need to tell install(1) that it should only expect a single directory as
> argument. so the -d flag needs to be passed over to install(1), while options
> such as -o X, -g X, etc. need to be stripped away.
The attached patch should fix this:
{{{
$ sh install.sh.orig -d -m 700 `pwd`/a-test
$ ls -ld a-test
drwx-- 2 rea rea 512 4 Feb 10:03 a-test
$ sh install.sh -d -m 700 `pwd`/a-test
$ ls -ld a-test
drwxr-xr-x 2 rea rea 512 4 Feb 10:03 a-test
}}}
It also adds some proper quoting for the remaining arguments (plain $*
vs quoted "$@") to the install.sh (this is a pathological case, but it
is better to fix this too, while we're on topic):
{{{
$ rm -rf 1; mkdir 1; cd 1; sh -x ../install.sh.orig -d -m 512 "this is a test";
ls -l; cd ..
+ [ 4 -gt 0 ]
+ break
+ exec install -p -d -m 512 this is a test
total 8
dr-x--x-w- 2 rea rea 512 Feb 4 10:10 a
dr-x--x-w- 2 rea rea 512 Feb 4 10:10 is
dr-x--x-w- 2 rea rea 512 Feb 4 10:10 test
dr-x--x-w- 2 rea rea 512 Feb 4 10:10 this
$ rm -rf 1; mkdir 1; cd 1; sh -x ../install.sh -d -m 512 "this is a test"; ls
-l; cd ..
+ dirmode=''
+ [ 4 -gt 0 ]
+ dirmode=YES
+ shift
+ [ 3 -gt 0 ]
+ shift
+ shift
+ [ 1 -gt 0 ]
+ break
+ [ 1 -eq 0 ]
+ [ -z YES ]
+ install -d 'this is a test'
total 2
drwxr-xr-x 2 rea rea 512 Feb 4 10:10 this is a test
}}}
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
--- install.sh.orig 2011-02-04 09:57:39.0 +0300
+++ install.sh 2011-02-04 10:03:05.0 +0300
@@ -29,8 +29,10 @@
# $FreeBSD$
# parse install's options and ignore them completely.
+dirmode=""
while [ $# -gt 0 ]; do
case $1 in
+-d) dirmode="YES"; shift;;
-[bCcMpSs]) shift;;
-[Bfgmo]) shift; shift;;
-[Bfgmo]*) shift;;
@@ -38,5 +40,16 @@
esac
done
+if [ "$#" -eq 0 ]; then
+ echo "Nothing to do: no files/dirs specified" >&2
+ exit 1
+fi
+
# the remaining arguments are assumed to be files/dirs only.
-exec install -p $*
+if [ -z "$dirmode" ]; then
+ exec install -p "$@"
+else
+ for d in "$@"; do
+ install -d "$d"
+ done
+fi
pgpzyMbPsPOSI.pgp
Description: PGP signature
Re: binding non local ip.
Fri, Jan 07, 2011 at 01:57:21PM +0100, joris dedieu wrote:
> What do you think about it ?
[...]
> +static int bindany = 0; /* 1 allows to bind a non local ip */
> +SYSCTL_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW, &bindany, 0,
> +"Allow to bind a non local ip");
On at least 8.x, you will likely want to use VNET_* macros to enable
your new sysctl to be virtualized. Something like this:
{{{
VNET_DEFINE(int, inp_bindany) = 0;
SYSCTL_VNET_INT(_net_inet_ip, OID_AUTO, bindany, CTLFLAG_RW,
&VNET_NAME(inp_bindany), 0, "Force INP_BINDANY on all sockets");
}}}
and use VNET(inp_bindany) in subsequent code.
> if ((inp->inp_flags & INP_BINDANY) == 0 &&
> - ifa_ifwithaddr_check((struct sockaddr *)sin) == 0)
> - return (EADDRNOTAVAIL);
> + ifa_ifwithaddr_check((struct sockaddr *)sin) ==
> 0) {
> + if(bindany > 0)
> + inp->inp_flags |= INP_BINDANY;
> + else
> + return (EADDRNOTAVAIL);
> + }
The check is better to be rewritten as
{{{
if (VNET(inp_bindany) > 0)
inp->inp_flags |= INP_BINDANY;
else if ((inp->inp_flags & INP_BINDANY) == 0 &&
ifa_ifwithaddr_check((struct sockaddr *)sin) == 0)
return (EADDRNOTAVAIL);
}}}
it will save you two conditionals if bindany is enabled. On the other
hand, if you will set the value of VNET(inp_bindany) to INP_BINDANY
instead of 1, you can even do
{{{
inp->inp_flags |= VNET(inp_bindany);
if ((inp->inp_flags & INP_BINDANY) == 0 &&
ifa_ifwithaddr_check((struct sockaddr *)sin) == 0)
return (EADDRNOTAVAIL);
}}}
and this will eliminate one branching instruction at the expense of
memory access and fast logical operation.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpbHhA7Pc69T.pgp
Description: PGP signature
Re: questions relating to ncurses and dialog(1)
Fri, Dec 31, 2010 at 01:39:03PM -0500, Eitan Adler wrote: > Thank you. I was stuck for a week on the ncurses issue - but now I > don't think I will have that problem anymore. :-} No problems, glad to help ;)) While we're on this topic, may I suggest to meld two buttons, "Accept the license" and "Reject the license" into a single checkbox named "Accept the license": this will - make the current status of acceptance to be visible; - remove one graphical element to reduce the overall number of them. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpuXu1SPaY2W.pgp Description: PGP signature
Re: questions relating to ncurses and dialog(1)
Thu, Dec 30, 2010 at 07:03:44PM -0500, Eitan Adler wrote:
> 2) The "help" screen just doesn't show up despite having text and a
> border and not generating any errors (which are all checked)
You're using 'frameCols' while calculating
windowStatList[HELP].rowStart, so your window is starting somewhere
around line 76 at the 80x25 terminal, thus it is just invisible.
Use 'frameRows' and you'll get something that will be top-aligned
with the buttons.
There's one more thing: the lone 'dialog4ports --hfile='
will dump core, because prev is NULL in this case.
The attached patch should fix the first item and will apply
a quick-fix for the second one.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
From 824820c0c938bf677728314477664f190448a648 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin
Date: Fri, 31 Dec 2010 13:46:08 +0300
Subject: [PATCH] Fix help handling
- we should use frame's rows when calculating the starting line
for the help window;
- we should check if there was a previous argument that can have
--hfile for it.
The latter fix is a quick one, we should really check that the
previous argument was one of the --option, --radio or --input.
Signed-off-by: Eygene Ryabinkin
---
dialog4ports.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/dialog4ports.c b/dialog4ports.c
index 026b0b9..cc7a9f8 100644
--- a/dialog4ports.c
+++ b/dialog4ports.c
@@ -385,6 +385,8 @@ parseArguments(const int argc, char * argv[])
stage = OPEN;
}
else if (stage == PREV_HFILE) {
+ if (prev == NULL)
+errx(EX_USAGE, "--hfile requires previous --option, --radio or --input option.");
prev->longDescrFile = argv[arg];
stage = OPEN;
}
@@ -632,7 +634,7 @@ main(int argc, char* argv[])
else
windowStatList[LICENCE].colStart = 0;
- windowStatList[HELP].rowStart = frameCols - windowStatList[EXIT].rows - windowStatList[LICENCE].rows;
+ windowStatList[HELP].rowStart = frameRows - windowStatList[EXIT].rows - windowStatList[LICENCE].rows;
windowStatList[HELP].colStart = 0 ;
windowStatList[HELP].rows = 6;
windowStatList[HELP].cols = frameCols;
--
1.7.3.2
pgpTIG7vaj4xA.pgp
Description: PGP signature
Re: questions relating to ncurses and dialog(1)
Eitan, good day.
Thu, Dec 30, 2010 at 07:03:44PM -0500, Eitan Adler wrote:
> 1) When clicking the "View" button on the license window (using the
> withlicense.sh script) I fork() and then exec less. Less opens fine -
> but when I hit "q" it seems that any actions I took in less also took
> place in the ncurses program. If I use rfork(RFPROC|RFCFDG) then it
> never shows less on the screen. I suspect this is because in the
> former case they share the same stdin and stdout and in the latter
> case less doesn't get any std* streams.
> Is there a way to avoid this problem?
The attached patch should fix it. The problem is that you should
leave the Ncurses mode before spawning external programs. You seem
to be trying to do it in the child process (commented endwin()), but
it should be done inside the parent process, since it is the one who
does Ncurses. And the most logical way is to
- leave the curses mode;
- invoke anything you like and wait() for it;
- enter the curses mode again + refresh the windows.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
From 1c6ca9f805e965796e7321d04868c1278d4ec7a9 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin
Date: Fri, 31 Dec 2010 10:47:46 +0300
Subject: [PATCH] Save/restore terminal around the pager invocation
We should leave Ncurses mode before the pager is spawned
and return to the saved mode once we're done with the pager.
Signed-off-by: Eygene Ryabinkin
---
dialog4ports.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/dialog4ports.c b/dialog4ports.c
index cdec074..026b0b9 100644
--- a/dialog4ports.c
+++ b/dialog4ports.c
@@ -888,6 +888,8 @@ main(int argc, char* argv[])
if (curItem == licenceItems[licenceVIEW]) {
char const * const pager = getenv("PAGER");
//const int pid = rfork(RFPROC|RFCFDG);
+ def_prog_mode();
+ endwin();
const int pid = fork();
if (pid == 0) {
//endwin();
@@ -903,6 +905,8 @@ main(int argc, char* argv[])
else {
wait(pid);
}
+ reset_prog_mode();
+ wrefresh(curscr);
}
}
else if (whichLocation == EXIT) {
--
1.7.3.2
pgpp4HNAfCu0C.pgp
Description: PGP signature
Re: "Checksum mismatch -- will transfer entire file"
Victor, good day.
Thu, Dec 31, 2009 at 09:32:44AM +0600, Victor Sudakov wrote:
> I cvsup the FreeBSD CVS repository daily from cvsup.ru.freebsd.org.
> Both the client and the server run CVSup Software version: SNAP_16_1h,
> Protocol version: 17.0.
>
> Recently I noticed that there are lots of messages
> "Checksum mismatch -- will transfer entire file" about all kinds of
> downloaded files, e.g.
http://old.nabble.com/CVSup-src-file-Edits-almost-alway-triggering-Checksum-mismatch-and-Fixup-td24980888.html
Seems like you're facing the same problem. Simon Nielsen had described
its origins, but it seems that the thread is currently dead.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bad source in the distro iso's
Trever wrote:
> I noticed in 7.2 that the /usr/src installed from the ISO downloads
> would not build without first sup'ing for a few updates.
> (disc1.iso's)
>
> I notice in the 8.0RC2&3 that some of the source files are corrupted.
Can you be precise in what's going wrong? What objects can't be built,
what are error messages, etc?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Issue with grep -i (on i386 only?)
Mel, good day.
Tue, Nov 03, 2009 at 09:22:28PM +0100, Mel Flynn wrote:
> So on the laptop I modified the testscript as it is attached now and
> while there is still a significant delay, the wallclock time is less
> then half, when the expression is rewritten with the same meaning:
> =>>> 16777216
> =>>> fgrep
> 0.04 real 0.03 user 0.00 sys
> 0.05 real 0.03 user 0.01 sys
> 0.02 real 0.00 user 0.00 sys
> =>>> pcregrep
> 0.26 real 0.21 user 0.02 sys
> 0.26 real 0.22 user 0.02 sys
> 0.44 real 0.35 user 0.01 sys
> =>>> grep
> 0.04 real 0.04 user 0.00 sys
> 4.45 real 4.15 user 0.01 sys
> 2.00 real 1.81 user 0.00 sys <-- [fF][Oo][Oo]
Just did a quick test on the 8.0-RC2/i386 with very old Athlon processor:
-
=>>> 16777216
=>>> fgrep
0,09 real 0,04 user 0,05 sys
0,18 real 0,06 user 0,03 sys
0,05 real 0,01 user 0,04 sys
=>>> pcregrep
0,47 real 0,29 user 0,07 sys
0,52 real 0,33 user 0,07 sys
0,77 real 0,45 user 0,03 sys
=>>> grep
0,09 real 0,08 user 0,01 sys
0,10 real 0,04 user 0,05 sys
0,23 real 0,12 user 0,03 sys
-
Pattern for the plain 'grep' is stable: first and second variants always
give the same time within a 0.01 second variation and the last variant
gives 2x slowdown.
I tried sizes up to the 64M -- the pattern stays. The same stuff for
the amd64, so in my case I don't see the difference in behaviour. So,
maybe, the problem isn't 32 vs 64 but lies somewhere else.
> attached a little test script for grep's -i performance.
Some notes about the script, especially if (or some variant of it)
will be included to the testing framework.
> #!/bin/sh
> # vim: ts=4 sw=4 noet tw=78 ai
>
> PCREGREP=`which pcregrep`
> BSDGREP=`which bsdgrep`
> [ -n ${PCREGREP} ] && PCREGREP=`basename ${PCREGREP}`
> [ -n ${BSDGREP} ] && BSDGREP=`basename ${BSDGREP}`
You'll want '[ -n "${PCREGREP}" ] && ...' (with quoted variable) to
really achieve the kind of test you wanted.
> if [ ! -x /usr/bin/jot ]; then
> echo "Need jot"
> exit 1
> fi
> if [ ! -x /usr/bin/rs ]; then
> echo "Need rs"
> exit 1
> fi
Probably this is better be written as
-
for prog in jot rs; do
if [ -z "`which "$prog"`" ]; then
echo "Need $prog"
exit 1
fi
done
-
because the latter code uses unqualified 'jot' and 'rs'.
> for b in ${BYTES}; do
> TMPFILE=`mktemp -t ${me}`
> if [ ! -f ${TMPFILE} ]; then
> echo Can\'t create tmp files in ${TMPDIR:="/tmp"}
> exit 2
> fi
> jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE}
> echo "=>>> ${b}"
> for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do
> echo "=>>> ${prog}"
> /usr/bin/time ${prog} foo ${TMPFILE} >/dev/null
> /usr/bin/time ${prog} -i foo ${TMPFILE} >/dev/null
> /usr/bin/time ${prog} '[fF][Oo][Oo]' ${TMPFILE} >/dev/null
> done
> rm ${TMPFILE}
> done
Most likely, it is better to create the temporary file only once
and to trap the signals with the file removal -- this will handle
the cases when user presses ^C during the execution -- temporary
file should be cleaned in this case. The code is simple:
-
TMPFILE=`mktemp -t ${me}`
if [ ! -f ${TMPFILE} ]; then
echo "Can't create tmp file in ${TMPDIR:=/tmp}"
exit 2
fi
trap 'rm -f "${TMPFILE}"' 0 1 2 3 15
-
Attaching modified version with the bonus -- 'K' and 'M' size prefixes:
it was boring to specify many digits when I had played with sizes ;))
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
Mon, Nov 02, 2009 at 10:32:29PM +0100, Alexander Best wrote:
> ok. the pr stays in patched state. right now the patch is in HEAD,
> 8-STABLE and 8.0-RELEASE. rafan is thinking about mfc'ing the patch to
> 6-stable and 7-stable. however if somebody is willing to modify the
> patch so it applies to those branches that'll be great
Patch applies cleanly to the 7-STABLE, moreover, lib_getch.c from it
has the same logics and fifo_push is essentially unmodified in the
areas that are relevant for this flaw.
I had patched 7-STABLE on the test machine, brought ee from 8.x and
verified that unpatched ncurses give immediate exit, while patched
curses give working ee in respect to the SIGWINCH.
I had also mildly tested vi and sysinstall on the patched 7-STABLE
and found no visible regressions.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ptrace problem 6.x/7.x - can someone explain this?
Dorr, good day.
Tue, Oct 27, 2009 at 05:32:34PM -0700, Dorr H. Clark wrote:
> We believe ptrace has a problem in 6.3; we have not tried other
> releases. The same code, however, exists in 7.1.
And in HEAD too.
> The bug was first encountered in gdb...
>
> (gdb) det
> Detaching from program: /usr/local/bin/emacs, process 66217
> (gdb) att 66224
> Attaching to program: /usr/local/bin/emacs, process 66224
> Error accessing memory address 0x281ba5a4: Device busy.
> (gdb) det
> Detaching from program: /usr/local/bin/emacs, process 66224
> ptrace: Device busy.
> (gdb) quit<--- target process 66224 dies here
>
> To isolate this problem, a wrote a simple minded test program was
> written that just attached and detached. This test program found
> even the very first detach fails with EBUSY (see test source below):
>
> $ ./test1 -p 66217 -c 1 -d 10
> pid 66217 count 1 delay 10
> Start of pass 0
> Calling PT_ATTACH pid 66217 addr 0x0 sig 0
> Calling PT_DETACH pid 66217 addr 0x sig 0
> Call 0 to PT_DETACH returned -1, errno 16
>
> Once again, the target process died when the ptracing test program
> exitted, as would be expected if a detach had failed.
>
> The failure return was coming from the following test in kern_ptrace()
> in sys_process.c
>
> /* not currently stopped */
> if ((p->p_flag & (P_STOPPED_SIG | P_STOPPED_TRACE)) == 0 ||
> p->p_suspcount != p->p_numthreads ||
> (p->p_flag & P_WAITED) == 0) {
> error = EBUSY;
> goto fail;
> }
Yes, the ptraced process should have been waited for, even after
the PT_ATTACH call. This is somewhat documented in ptrace(2),
-
-
but I agree that the wording is a bit sloppy. I'll try to produce
slightly modified explanation in the manual page and will post the patch
here and as the PR.
I had modified your example to visually display the results of
each wait() call that is made after ptrace() invocation. Here we go:
-
$ ./test -p 45901
pid 45901 count 2 delay 5
Start of pass 0
Calling PT_ATTACH pid 45901 addr 0x0 sig 0
Attached
wait() yield 0x117f: stopped by signal 17; <-- after PT_ATTACH
wait() yield 0x57f: stopped by signal 5; <-- after PT_STEP
Calling PT_DETACH pid 45901 addr 0x sig 0
Detached.
-
As you see, the process is stopped just after the PT_ATTACH with the
signal 17, SIGSTOP. PT_STEP follows with the delivery of the SIGTRAP.
Both of these signals should be processed by the parent's wait().
And PT_DETACH works, apart from one thing: on my 8.0 PT_DETACH leads to
the segfault of the traced program. I hadn't yet tried it on the other
versions, so may be there is some bug in the code of test.c, or some bug
in the ptrace() implementation -- can't say for sure. If anyone knows
why the program segfaults -- please, speak up. The modified source of
the test.s is attached.
> This is applied to all operations except PT_TRACE_ME, PT_ATTACH, and
> some instances of PT_CLEAR_STEP.
>
> P_WAITED is generally not true. In particular, it's not set
> automatically when a process is PT_ATTACHed. It is cleared by
> PT_DETACH and again when ptrace sends a signal (PT_CONTINUE,
> PT_DETACH.) _But_ it's set in only two places, and they aren't in
> ptrace code.
>
> 2 sys/kern/kern_exit.c kern_wait 773 p->p_flag |= P_WAITED;
> 3 compat/svr4/svr4_misc.c svr4_sys_waitsys 1351 q->p_flag |= P_WAITED;
>
> The relevant one is the first one, primarily. Here's the code:
>
> mtx_lock_spin(&sched_lock);
> if ((p->p_flag & P_STOPPED_SIG) &&
> (p->p_suspcount == p->p_numthreads) &&
> (p->p_flag & P_WAITED) == 0 &&
> (p->p_flag & P_TRACED || options & WUNTRACED)) {
> mtx_unlock_spin(&sched_lock);
> p->p_flag |= P_WAITED;
> sx_xunlock(&proctree_lock);
> td->td_retval[0] = p->p_pid;
> if (status)
> *status = W_STOPCODE(p->p_xstat);
> PROC_UNLOCK(p);
> return (0);
> }
> mtx_unlock_spin(&sched_lock);
>
> So it's only set on processes which are already traced. But it's not
> set until someone calls wait4() on them - or the equivalent sysV
> compatability routine.
>
> Gdb doesn't always wait4() for processes immediately opon tracing
> them, and the ptrace man page does not imply this is needed.
Hmm, there is at least one thread on the simular matter,
http://sourceware.org/ml/gdb/2008-12/msg00041.html
and people are saying that wait() still should be present.
> Moreover, it's not clear why it should matter. The process
> needs to be stopped in order for it to make sense to do most
> of the things ptrace does. But - why should it need to be waited fo
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
Sat, Oct 24, 2009 at 02:04:34PM +0200, Jilles Tjoelker wrote:
> That should be:
> -
> do
> in = wgetch(text_win);
> while (in == -1 && errno == EINTR);
> if (in == -1)
> exit(0);
> -
>
> errno should only be checked after failed function calls or for
> functions where it is documented that errno should be used to check for
> error conditions (example: readdir).
True, thanks for correction!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
Ed, good day.
Fri, Oct 23, 2009 at 07:13:01PM +0200, Ed Schouten wrote:
> Have you sent it to Thomas Dickey as well?
Sent the patch to bug-ncur...@gnu.org. Do you think that I should
send it to Thomas directly as well?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
Fri, Oct 23, 2009 at 06:32:38PM +0200, Alexander Best wrote:
> thanks a million. for me the patch works great. :)
You're welcome ;))
> the sooner it gets committed the better. ;)
It may well break something else. I am not 100% sure that this patch
is the proper thing -- curses code is a bit new to me, so I would say
that the patch will need more thorough review from maintainers.
> since this problem is not limited to freebsd it would be nice if
> somebody could send the patch to the ncurses maintainers so all OSes
> using ncurses can profit from it.
Will also send this patch to bug-ncur...@gnu.org.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
Gentlemen, good day.
Fri, Oct 23, 2009 at 02:02:38PM +0200, Dag-Erling Sm??rgrav wrote:
> src/contrib/ee/ee.c in 8:
>
> in = wgetch(text_win);
> if (in == -1)
> exit(0); /* without this exit ee will go into an
> infinite loop if the network
> session detaches */
>
> >From the wgetch() man page:
>
>Programmers concerned about portability should be prepared for
>either of two cases: (a) signal receipt does not interrupt
>getch; (b) signal receipt interrupts getch and causes it to
>return ERR with errno set to EINTR. Under the ncurses
>implementation, handled signals never inter??? rupt getch.
Hmm, we can transform this code to the following one:
-
errno = 0;
do {
in = wgetch(text_win);
} while (errno == EINTR);
if (in == -1)
exit(0);
-
This won't help with FreeBSD's ncurses, but may be other variants
will feel much better with such a event loop variant.
> The real issue, though, is that when a SIGWINCH is caught, wgetch()
> correctly returns KEY_RESIZE, but the next call to wgetch() returns -1.
> The next call after that is fine. I suspect the error lies somewhere
> inside kgetch() in contrib/ncurses/ncurses/base/lib_getch.c.
The problem should be healed with the attached patch. And you're
partly right: this is kgetch() that is returning ERR for the second
wgetch(), but kgetch() shouldn't be blamed for this -- _nc_wgetch()
should. At least in my opinion ;)
Any views on this?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From d0b09b188c778858f44379546bcce05e8a279fe0 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin
Date: Fri, 23 Oct 2009 19:02:14 +0400
Subject: [PATCH] Ncurses: get ERR from the fifo when SIGWINCH is handled
fifo_pull() will put ERR to the buffer if read() will fail
for any reason. kgetch() will notice this ERR and won't
interpret any fifo contents setting peek = head. But when
_nc_wgetch() will handle SIGWINCH and KEY_RESIZE will be
pushed into fifo and taken out, ERR will still stay there.
We should take ERR from the fifo or kgetch() will return
ERR on all subsequent calls.
Signed-off-by: Eygene Ryabinkin
---
contrib/ncurses/ncurses/base/lib_getch.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/contrib/ncurses/ncurses/base/lib_getch.c b/contrib/ncurses/ncurses/base/lib_getch.c
index a3812be..e7ba0b2 100644
--- a/contrib/ncurses/ncurses/base/lib_getch.c
+++ b/contrib/ncurses/ncurses/base/lib_getch.c
@@ -476,6 +476,12 @@ _nc_wgetch(WINDOW *win,
/* resizeterm can push KEY_RESIZE */
if (cooked_key_in_fifo()) {
*result = fifo_pull(sp);
+ /*
+ * Get the ERR from queue -- it is from WINCH,
+ * so we should take it out, the "error" is handled.
+ */
+ if (fifo_peek(sp) == -1)
+ fifo_pull(sp);
returnCode(*result >= KEY_MIN ? KEY_CODE_YES : OK);
}
}
--
1.6.4.4
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Problem in bin/sh stripping the * character through ${expansion%}
Doug, good day.
Thu, Aug 06, 2009 at 11:15:12AM -0700, Doug Barton wrote:
> I came across this problem during a recent portmaster update. When
> trying to strip off the * character using variable expansion in bin/sh
> it doesn't work. Other "special" characters do work if they are
> properly escaped.
>
> The attached mini-script clearly shows the problem:
>
> $ sh sh-strip-problem
> var before stripping: foo\*
> var after stripping: foo\*
>
> var before stripping: foo\$
> var after stripping: foo\
According to the sh(1), it is not a problem. Namely,
- \* being unquoted at all will produce a lone '*';
- '*' when treated as the smallest pattern, will result in a stripping
of a zero-length string -- it is the smallest pattern in the case of
'*' that matches anything.
In order to strip the trailing star you should use
-
var=${var%[*]}
-
This gives you the pattern of '[*]' that is properly treated as the
single star -- it's a weird way to escape the star in the patterns.
Other characters work, but only because they produce no patterns.
In principle, you can try \? that will remove any trailing character
no matter what, since it is the second character that will produce
the pattern.
> In contrast, bash does the right thing:
>
> bash sh-strip-problem
> var before stripping: foo\*
> var after stripping: foo\
>
> var before stripping: foo\$
> var after stripping: foo\
I will try to look at the XCU to understand what is the POSIX
way of doing the things.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Wed, Jun 03, 2009 at 11:03:45AM +0200, Dag-Erling Sm??rgrav wrote:
> Isn't it clearly described in the preceding comment? Specifically, by
> the first two sentences: "Replace multiple slashes by a single slash and
> trailing slashes by a null. This must be done before VOP_LOOKUP()
> because some fs's don't know about trailing slashes."
Yes, it is clearly described. But I started to understand this
description only after asking myself "what ndp->ni_next is doing here
and why do we want to place '\0' to this address"? I could be a bit
stupid, yeah ;)) But this code snippet can be a bit hard to read for
others as well. May be not -- can't say for sure.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Tue, Jun 02, 2009 at 01:28:34PM +0200, Dag-Erling Sm??rgrav wrote:
> Eygene Ryabinkin writes:
> > For the current code state, check "*cp == '\0'" seems to be redundant:
> > [...] By the way, comment before the test "if (rdonly)' seems to be
> > slightly misleading [...]
>
> OK, I see that. I've removed the check and rewritten the comment.
Thanks.
> What about this "temporary assert"?
>
> /*
>* This is a temporary assert to make sure I know what the
>* behavior here was.
>*/
> KASSERT((cnp->cn_flags & (WANTPARENT|LOCKPARENT)) != 0,
> ("lookup: Unhandled case."));
It is partly handled at the beginning of lookup:
-
wantparent = cnp->cn_flags & (LOCKPARENT | WANTPARENT);
KASSERT(cnp->cn_nameiop == LOOKUP || wantparent,
("CREATE, DELETE, RENAME require LOCKPARENT or WANTPARENT."));
-
So, only LOOKUP could have both {LOCK,WANT}PARENT to be unset. And it
seems to be fine, because LOOKUP shouldn't care about parent vnode,
either locked or just referenced. So this assertion seems to be really
redundant.
> > Seems like here we can also check for the trailing slash to be set on
> > any previous invocation (or the current one), since we're following
> > symlinks in the case of directories, so we should follow them to the
> > end.
>
> I'm not sure I understand...
I meant the following: you're trading 'trailing_slash' to the
TRAILINGSLASH. The former is local to this call of lookup(), the latter
persists throughout the namei() invocation, so it could be set by the
previous lookup() calls. But this seems to be fine: since we were
started to look for directory at some point, we should continue to do
it.
> > Perhaps 'XXX for direnter()' should be changed to something like
> > 'strip trailing slashes in cnp->cn_nameptr'.
>
> I'll just remove it, since the previous comment clearly explains what is
> going on.
May be it's better to leave the comment, but replace it with more
undestandable one: this instruction is a bit tricky and it makes one to
think what the hell is going on.
> > By the way, comment just after 'nextname' label is misleading: we can be
> > there with symbolic link, but it won't be followed. So "Not a symbolic
> > link" can be changed to something like "Not a symbolic link that will
> > be followed".
>
> /*
>* Not a symbolic link that we will follow. Continue with the
>* next component if there is any; otherwise, we're done.
>*/
Yes, very good.
Thanks.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling, good day.
Fri, May 29, 2009 at 06:58:08PM +0200, Dag-Erling Sm??rgrav wrote:
> Index: sys/kern/vfs_lookup.c
> ===
> --- sys/kern/vfs_lookup.c (revision 193028)
> +++ sys/kern/vfs_lookup.c (working copy)
> @@ -454,7 +454,6 @@
> int docache;/* == 0 do not cache last component */
> int wantparent; /* 1 => wantparent or lockparent flag */
> int rdonly; /* lookup read-only flag bit */
> - int trailing_slash;
> int error = 0;
> int dpunlocked = 0; /* dp has already been unlocked */
> struct componentname *cnp = &ndp->ni_cnd;
> @@ -529,12 +528,10 @@
>* trailing slashes to handle symlinks, existing non-directories
>* and non-existing files that won't be directories specially later.
>*/
> - trailing_slash = 0;
> while (*cp == '/' && (cp[1] == '/' || cp[1] == '\0')) {
> cp++;
> ndp->ni_pathlen--;
> if (*cp == '\0') {
> - trailing_slash = 1;
> *ndp->ni_next = '\0'; /* XXX for direnter() ... */
> cnp->cn_flags |= TRAILINGSLASH;
> }
> @@ -711,7 +708,7 @@
> error = EROFS;
> goto bad;
> }
> - if (*cp == '\0' && trailing_slash &&
> + if (*cp == '\0' && (cnp->cn_flags & TRAILINGSLASH) &&
>!(cnp->cn_flags & WILLBEDIR)) {
For the current code state, check "*cp == '\0'" seems to be redundant:
VOP_LOOKUP had failed at this point and we're running with EJUSTRETURN.
And EJUSTRETURN can happen only if ISLASTCN is set, that in turn implies
that *ndp->ni_next is 0 and ndp->ni_next is equal to the cp.
Seems like this change makes symlink behavior more consistent: if any
previous component had a trailing slash, then we will bail out unless
we intend to create/rename directory.
By the way, comment before the test "if (rdonly)' seems to be slightly
misleading: we could be not only creating the file but could be renaming
at this point as well. Perhaps 'creating' should be changed to
'creating/renaming'.
> error = ENOENT;
> goto bad;
> @@ -788,7 +785,7 @@
>* Check for symbolic link
>*/
> if ((dp->v_type == VLNK) &&
> - ((cnp->cn_flags & FOLLOW) || trailing_slash ||
> + ((cnp->cn_flags & FOLLOW) || (cnp->cn_flags & TRAILINGSLASH) ||
>*ndp->ni_next == '/')) {
> cnp->cn_flags |= ISSYMLINK;
> if (dp->v_iflag & VI_DOOMED) {
Seems like here we can also check for the trailing slash to be set on
any previous invocation (or the current one), since we're following
symlinks in the case of directories, so we should follow them to the
end.
> BTW, what does the "XXX for direnter()" comment mean?
It means that the trailing slashes are eliminated because direnter() for
some FSes may choke on it. It essentially duplicates the chunk of a big
comment before the block. 'ngp->ni_next' is set to 'cp' before the
block and at that time 'cp' points to a slash that delimits directories
or null character that terminates non-slashed name.
Perhaps 'XXX for direnter()' should be changed to something like
'strip trailing slashes in cnp->cn_nameptr'.
By the way, comment just after 'nextname' label is misleading: we can be
there with symbolic link, but it won't be followed. So "Not a symbolic
link" can be changed to something like "Not a symbolic link that will
be followed".
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Fri, May 29, 2009 at 06:53:22PM +0200, Dag-Erling Sm??rgrav wrote:
> Bruce Evans writes:
> > % /*
> > %* Get a buffer for the name to be translated, and copy the
> > %* name into the buffer.
> > % @@ -533,6 +536,8 @@
> > % if (*cp == '\0') {
> > % trailing_slash = 1;
> >
> > I thought at first that this flag can go away.
>
> I intend to remove it later - I just wanted to get the bug fixed first.
> I'm happy to hear that removing it will fix the two bugs introduced by
> the patch I committed :)
What are those bugs?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Mel, good day.
Thu, May 28, 2009 at 11:07:12AM +0200, Mel Flynn wrote:
> On Tuesday 26 May 2009 23:20:01 Dag-Erling Sm??rgrav wrote:
> > Dag-Erling Sm??rgrav writes:
> > > Like bde@ pointed out, the patch is incorrect. It moves the test for
> > > v_type != VDIR up to a point where, in the case of a symlink, v_type is
> > > always (by definition) VLNK.
> >
> > Hmm, actually, symlinks are resolved in namei(), not lookup(). This is
> > not going to be pretty. I'll be back later...
> I don't pretend to comprehend the kernel side of things fully, but
> wouldn't it be easier to append a dot to all trailing slashes inside
> or before passing to namei?
A dirty hack that puts some additional burden on the namei() ;-/
> This works in userland at present and lighttpd could use something
> similar as a work around until it's fixed:
Yes, this will work, but it is better to apply the real fix ;)) Dirty
hacks aren't good at the long timescales -- they tend to obfuscate the
code and put unneeded interprocedure constraints (you should prepend dot
to the slash if you want to call namei()/we should add dot to slash to
make our life easier/etc).
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Wed, May 27, 2009 at 06:44:35PM +0200, Dag-Erling Sm??rgrav wrote:
> Eygene Ryabinkin writes:
> > [new three-part patch]
>
> I committed the namei.h cleanup patch and the vfs_lookup.c comment
> patch.
Thanks!
> I made a number of changes to the trailing-slash patch. Can you
> double-check it before I commit it?
Yes, comments are below.
> Index: sys/kern/vfs_lookup.c
> ===
> --- sys/kern/vfs_lookup.c (revision 192899)
> +++ sys/kern/vfs_lookup.c (working copy)
> @@ -147,6 +147,9 @@
> cnp->cn_flags &= ~LOCKSHARED;
> fdp = p->p_fd;
>
> + /* We will set this ourselves if we need it. */
> + cnp->cn_flags &= ~TRAILINGSLASH;
> +
> /*
>* Get a buffer for the name to be translated, and copy the
>* name into the buffer.
> @@ -533,6 +536,8 @@
> if (*cp == '\0') {
> trailing_slash = 1;
> *ndp->ni_next = '\0'; /* XXX for direnter() ... */
> + if (cnp->cn_flags & ISLASTCN)
> + cnp->cn_flags |= TRAILINGSLASH;
'if ()' looks suspicious: ISLASTCN is set some lines below so it could
be not yet flagged. Seems like we could omit 'if ()' clause but leave
it's body for the current state of the code -- it will be equivalent to
the mine's check.
But for the clarity, I will leave the full condition, 'trailing_slash &&
(cnp->cn_flags & ISLASTCN)' somewhere below the block with
-
if (*ndp->ni_next == 0)
cnp->cn_flags |= ISLASTCN;
else
cnp->cn_flags &= ~ISLASTCN;
-
My original intent was to push it to the bottom of the code to slightly
optimize code path: some checks above could already fail and we won't
have to perform our test. But now I feel that the best place for the
test is immediately below the cited chunk of the code.
The rest looks fine. Had you tried your variant of patch? May be I
am missing something and the test for ISLASTCN really in place?
By the way, I had somewhat extended your regression tests with the
intermediate symlink tests, directory tests and device-as-a-target
tests. Patches are attached. Will they go?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 8ed2a144245bdb714217f982f6ee1f7d0b784b1c Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin
Date: Wed, 27 May 2009 20:55:50 +0400
Subject: [PATCH 4/5] vfs regression testuite: add double links and directory tests
Directory tests are to make sure that no regressions were introduced by
patches -- they should work on the systems without patched vfs_lookup as
at the patched ones.
Double link tests should verify that if any part of the symlink chain
has trailing slash, then target should be a directory.
Signed-off-by: Eygene Ryabinkin
---
tools/regression/vfs/trailing_slash.t | 67 -
1 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/tools/regression/vfs/trailing_slash.t b/tools/regression/vfs/trailing_slash.t
index fe6d799..5209979 100755
--- a/tools/regression/vfs/trailing_slash.t
+++ b/tools/regression/vfs/trailing_slash.t
@@ -6,8 +6,10 @@
# point to files. See kern/21768
#
+testdir="/tmp/testdir-$$"
testfile="/tmp/testfile-$$"
testlink="/tmp/testlink-$$"
+testlink1="/tmp/testlink1-$$"
tests="
$testfile:$testlink:$testfile:0
@@ -18,8 +20,29 @@ $testfile/:$testlink:$testlink:1
$testfile/:$testlink:$testlink/:1
"
+tests1="
+$testfile:$testlink:$testlink:$testlink1:$testlink1:0
+$testfile:$testlink:$testlink/:$testlink1:$testlink1:1
+$testfile:$testlink:$testlink:$testlink1:$testlink1/:1
+$testfile:$testlink:$testlink/:$testlink1:$testlink1/:1
+$testfile/:$testlink:$testlink:$testlink1:$testlink1:1
+$testfile/:$testlink:$testlink/:$testlink1:$testlink1:1
+$testfile/:$testlink:$testlink:$testlink1:$testlink1/:1
+$testfile/:$testlink:$testlink/:$testlink1:$testlink1/:1
+"
+
+dirtests="
+$testdir:$testlink:$testdir:0
+$testdir:$testlink:$testdir/:0
+$testdir:$testlink:$testlink:0
+$testdir:$testlink:$testlink/:0
+$testdir/:$testlink:$testlink:0
+$testdir/:$testlink:$testlink/:0
+"
+
touch $testfile || exit 1
-trap "rm $testfile $testlink" EXIT
+mkdir $testdir || exit 1
+trap "rm $testfile $
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Wed, May 27, 2009 at 02:39:07PM +0200, Dag-Erling Sm??rgrav wrote:
> I was working on head. The code is (mostly) the same, just shifted
> somewhere between ~50 and ~90 lines depending on where you look. Your
> patch should apply cleanly.
>
> BTW, you made a lot of whitespace changes in namei.h. This is generally
> frowned upon, as it makes the functional change almost impossible to
> spot in the diff.
Yes, spit the patch into two pieces. Thanks for the reminder!
> > And yes, I know what was meant by '(cnp->cn_flags & ISSYMLINK) == 0'
> > ;))
>
> I know you know :) I was just pointing out that the comment is
> misleading.
Changed it too. All three pieces are attached.
Regarding the 'ln -s /etc/motd file; ln -s file/ anotherone': do you
(or anyone reading this) think that 'cat anotherone' should really
show the contents of /etc/motd or patch's behaviour is good?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 03483c8e800680a8b8a3d3f0d1debdf7fd883906 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin
Date: Wed, 27 May 2009 13:13:16 +0400
Subject: [PATCH 1/3] vfs lookups: properly handle the case of slash at the end of symlink
If symlink points to a non-directory object but the name has trailing
slash, then the current lookup/namei implementation will dereference
symlink and return dereferenced object instead of symlink even if
NOFOLLOW mode is used. That's not good at all :((
Simple test:
-
$ ln -s /etc/motd file
$ file file
file: symbolic link to `/etc/motd'
[ == Unpatched variant == ]
$ file file/
file/: ASCII English text
[ == Patched variant == ]
$ file file/
file/: cannot open `file/' (Not a directory)
-
See also: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
See also: http://lists.freebsd.org/pipermail/freebsd-security/2009-May/005219.html
Signed-off-by: Eygene Ryabinkin
---
sys/kern/vfs_lookup.c | 24
sys/sys/namei.h |3 ++-
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 3770b55..dc801fd 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -138,6 +138,9 @@ namei(struct nameidata *ndp)
cnp->cn_flags &= ~LOCKSHARED;
fdp = p->p_fd;
+ /* Drop internal flag: we will set it ourselves if we'll need it. */
+ cnp->cn_flags &= ~SLASHTARGET;
+
/*
* Get a buffer for the name to be translated, and copy the
* name into the buffer.
@@ -683,6 +686,11 @@ unionlookup:
ndp->ni_vp = dp = tdp;
}
+ /* Set "slashed" flag if we found slash at the end of the name */
+ if (trailing_slash && (cnp->cn_flags & ISLASTCN)) {
+ cnp->cn_flags |= SLASHTARGET;
+ }
+
/*
* Check for symbolic link
*/
@@ -710,14 +718,6 @@ unionlookup:
goto success;
}
- /*
- * Check for bogus trailing slashes.
- */
- if (trailing_slash && dp->v_type != VDIR) {
- error = ENOTDIR;
- goto bad2;
- }
-
nextname:
/*
* Not a symbolic link. If more pathname,
@@ -741,6 +741,14 @@ nextname:
goto dirloop;
}
/*
+ * Check if we're processing slashed name
+ * and lookup target isn't a directory.
+ */
+ if ((cnp->cn_flags & SLASHTARGET) && dp->v_type != VDIR) {
+ error = ENOTDIR;
+ goto bad2;
+ }
+ /*
* Disallow directory write attempts on read-only filesystems.
*/
if (rdonly &&
diff --git a/sys/sys/namei.h b/sys/sys/namei.h
index ac3550d..70e902c 100644
--- a/sys/sys/namei.h
+++ b/sys/sys/namei.h
@@ -146,7 +146,8 @@ struct nameidata {
#define GIANTHELD 0x200 /* namei() is holding giant. */
#define AUDITVNODE1 0x400 /* audit the looked up vnode information */
#define AUDITVNODE2 0x800 /* audit the looked up vnode information */
-#define PARAMASK 0xe00 /* mask of parameter descriptors */
+#define SLASHTARGET 0x1000 /* last component of the name was slashed */
+#define PARAMASK 0x1e00 /* mask of parameter descriptors */
#define NDHASGIANT(NDP) (((NDP)->ni_cnd.cn_flags & GIANTHELD) != 0)
--
1.6.3.1
From 2539d4f31a2f85504672e8113343242782e737a7 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin
Date: Wed, 27 May 2009 17:06:39 +0400
Subject: [PATCH 2/3] namei.h: realign numbers
Functional no-op, just for the eye's pleasure.
Signed-off-by: Eygene Ryabinkin
---
sys/sys/namei.h | 39 ---
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/sys/sys/namei
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Wed, May 27, 2009 at 01:07:15PM +0200, Dag-Erling Sm??rgrav wrote:
> Eygene Ryabinkin writes:
> > May be the attached patch will fix the thing?
>
> I'm not entirely convinced. Try the regression test I wrote
> (head/tools/regression/vfs/trailing_slash.t)
I see: you mean that the bare '/' at the end of everything but directory
should produce ENOTDIR. OK, patch was modified and now it passes all
your checks.
> > It adds an additional flag, but this was the only thing I was able to
> > invent to avoid ABI breakage.
>
> The flag is a good idea, but I think the correct place to handle this is
> in namei(), around line 290
The problem with the check in namei() itself is the cleanup of all locks
that were held in the lookup(). If lookup() is finished without error,
then the burden of cleanup is ours (namei's). I could duplicate the
stuff, but why? lookup() already does it and it's better to keep the
things in one place.
The logics is laid as follows: if lookup() processes the last
component and it had seen the trailing slash, the flag is set.
When we have no more targets to get from the current path inside
lookup(), check if slashed flag is set and reject anything that
is non-directory.
Such strategy should also handle the cases of dereferencing (FOLLOWs) of
all symbolic links and when some link has slash at the end of the target
name: 'ln -s /etc/motd somefile; ln -s somefile/ anotherfile; cat
anotherfile' will fail on the last command. If one agrees on such
behaviour, such test could be also added to the regression suite.
> (don't be fooled by the comment on line 270;
> the code inside the if statement is for the *non*-symlink case).
Me sees this on the line 226, but may be I hadn't updated my 7.x. And
yes, I know what was meant by '(cnp->cn_flags & ISSYMLINK) == 0' ;))
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 6109a710c794c4a68073d4299639cd858f762d24 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin
Date: Wed, 27 May 2009 13:13:16 +0400
Subject: [PATCH] vfs lookups: properly handle the case of slash at the end of symlink
If symlink points to a non-directory object but the name has trailing
slash, then the current lookup/namei implementation will dereference
symlink and return dereferenced object instead of symlink even if
NOFOLLOW mode is used. That's not good at all :((
Simple test:
-
$ ln -s /etc/motd file
$ file file
file: symbolic link to `/etc/motd'
[ == Unpatched variant == ]
$ file file/
file/: ASCII English text
[ == Patched variant == ]
$ file file/
file/: cannot open `file/' (Not a directory)
-
See also: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
See also: http://lists.freebsd.org/pipermail/freebsd-security/2009-May/005219.html
Signed-off-by: Eygene Ryabinkin
---
sys/kern/vfs_lookup.c | 24
sys/sys/namei.h | 41 +
2 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 3770b55..dc801fd 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -138,6 +138,9 @@ namei(struct nameidata *ndp)
cnp->cn_flags &= ~LOCKSHARED;
fdp = p->p_fd;
+ /* Drop internal flag: we will set it ourselves if we'll need it. */
+ cnp->cn_flags &= ~SLASHTARGET;
+
/*
* Get a buffer for the name to be translated, and copy the
* name into the buffer.
@@ -683,6 +686,11 @@ unionlookup:
ndp->ni_vp = dp = tdp;
}
+ /* Set "slashed" flag if we found slash at the end of the name */
+ if (trailing_slash && (cnp->cn_flags & ISLASTCN)) {
+ cnp->cn_flags |= SLASHTARGET;
+ }
+
/*
* Check for symbolic link
*/
@@ -710,14 +718,6 @@ unionlookup:
goto success;
}
- /*
- * Check for bogus trailing slashes.
- */
- if (trailing_slash && dp->v_type != VDIR) {
- error = ENOTDIR;
- goto bad2;
- }
-
nextname:
/*
* Not a symbolic link. If more pathname,
@@ -741,6 +741,14 @@ nextname:
goto dirloop;
}
/*
+ * Check if we're processing slashed name
+ * and lookup target isn't a directory.
+ */
+ if ((cnp->cn_flags & SLASHTARGET) && dp->v_type != VDIR) {
+ error = ENOTDIR;
+ goto bad2;
+ }
+ /*
* Disallow directory write attempts on read-only filesystems.
*/
if (rdonly &&
diff --git a/sys/sys/namei.h b/sys/sys/namei.h
index ac3550d..42e9601 100644
--- a/sys/sys/namei.
Re: FYI Lighttpd 1.4.23 /kernel (trailing '/' on regular file symlink) vulnerability
Dag-Erling, *, good day.
Tue, May 26, 2009 at 10:13:21PM +0200, Dag-Erling Sm??rgrav wrote:
> [moving from security@ to hack...@]
>
> Jakub Lach writes:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
>
> Like bde@ pointed out, the patch is incorrect. It moves the test for
> v_type != VDIR up to a point where, in the case of a symlink, v_type is
> always (by definition) VLNK.
>
> The reason why the current code does not work is that, in the symlink
> case, the v_type != VDIR test is never reached: we will have jumped to
> either bad2 or success. However, it should be safe to move the test to
> after the success label, because trailing_slash is only ever true for
> the last component of the path we were asked to look up (see lines 520
> through 535).
May be the attached patch will fix the thing? It works for me for 7.2
with WITNESS and INVARIANTS enabled. It adds an additional flag, but
this was the only thing I was able to invent to avoid ABI breakage.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 029b779c2fe005fe0d043fb3f1990957927e6a18 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin
Date: Wed, 27 May 2009 13:13:16 +0400
Subject: [PATCH] vfs lookups: properly handle the case of slash at the end of symlink
If symlink points to a non-directory object but the name has trailing
slash, then the current lookup/namei implementation will dereference
symlink and return dereferenced object instead of symlink even if
NOFOLLOW mode is used. That's not good at all :((
Simple test:
-
$ ln -s /etc/motd file
$ file file
file: symbolic link to `/etc/motd'
[ == Unpatched variant == ]
$ file file/
file/: ASCII English text
[ == Patched variant == ]
$ file file/
file/: cannot open `file/' (Not a directory)
-
See also: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21768
See also: http://lists.freebsd.org/pipermail/freebsd-security/2009-May/005219.html
Signed-off-by: Eygene Ryabinkin
---
sys/kern/vfs_lookup.c | 25 +
sys/sys/namei.h | 41 +
2 files changed, 38 insertions(+), 28 deletions(-)
diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 3770b55..75b1772 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -138,6 +138,9 @@ namei(struct nameidata *ndp)
cnp->cn_flags &= ~LOCKSHARED;
fdp = p->p_fd;
+ /* Drop internal flag: we will set it ourselves if we'll need it. */
+ cnp->cn_flags &= ~SLASHSYMLINK;
+
/*
* Get a buffer for the name to be translated, and copy the
* name into the buffer.
@@ -683,6 +686,12 @@ unionlookup:
ndp->ni_vp = dp = tdp;
}
+ /* Set slashed symlink flag if we found slash at the end of symlink */
+ if (dp->v_type == VLNK && trailing_slash &&
+ (cnp->cn_flags & ISLASTCN)) {
+ cnp->cn_flags |= SLASHSYMLINK;
+ }
+
/*
* Check for symbolic link
*/
@@ -710,14 +719,6 @@ unionlookup:
goto success;
}
- /*
- * Check for bogus trailing slashes.
- */
- if (trailing_slash && dp->v_type != VDIR) {
- error = ENOTDIR;
- goto bad2;
- }
-
nextname:
/*
* Not a symbolic link. If more pathname,
@@ -741,6 +742,14 @@ nextname:
goto dirloop;
}
/*
+ * Check if we're processing slashed symlink and
+ * lookup target isn't a directory.
+ */
+ if ((cnp->cn_flags & SLASHSYMLINK) && dp->v_type != VDIR) {
+ error = ENOTDIR;
+ goto bad2;
+ }
+ /*
* Disallow directory write attempts on read-only filesystems.
*/
if (rdonly &&
diff --git a/sys/sys/namei.h b/sys/sys/namei.h
index ac3550d..d73da50 100644
--- a/sys/sys/namei.h
+++ b/sys/sys/namei.h
@@ -127,26 +127,27 @@ struct nameidata {
* name being sought. The caller is responsible for releasing the
* buffer and for vrele'ing ni_startdir.
*/
-#define RDONLY 0x200 /* lookup with read-only semantics */
-#define HASBUF 0x400 /* has allocated pathname buffer */
-#define SAVENAME 0x800 /* save pathname buffer */
-#define SAVESTART 0x0001000 /* save starting directory */
-#define ISDOTDOT 0x0002000 /* current component name is .. */
-#define MAKEENTRY 0x0004000 /* entry is to be added to name cache */
-#define ISLASTCN 0x0008000 /* this is last component of pathname */
-#define ISSYMLINK 0x001 /* symlink needs interpretation */
-#define ISWHITEOUT 0x002 /* found whiteout */
-#define DOWHITEOUT 0x004 /* do whiteouts */
-#define WILLBEDIR 0x008 /* new files will be dirs;
Re: bin/134694: gives false-positive when unable to obtain socket [WAS: sshd(8) - alert user when fails to execute from rc.d]
Glen, good day.
Mon, May 18, 2009 at 10:49:52PM -0400, Glen Barber wrote:
> Earlier this evening, I submitted a PR about sshd(8) giving a
> false-positive when starting on an already occupied socket[1]. I
> would like to enable some form of console output when the rc.d script
> is called if the service cannot properly bind to the socket, but I
> want to make sure I do it "the right way."
Reading through the PR, I can't figure out what do you mean.
You're saying that
1. you spawn the other service on a port N;
2. then you're spawning SSH on the same port via rc.d script;
3. after this '/etc/rc.d/sshd status' gives you 'sshd is not running'.
But this is completely right: after step 2 there will be no SSH daemon
listening, because it fails to bind to the port. And the 'status'
command of an rc.d script is perfectly correct -- no SSH daemon is
running, really.
> I was digging through src/crypto/openssh/sshd.c hoping to submit a
> patch to enable this, but I'm not certain that is the right place to
> be looking. After digging through erc/etc/rc.d/sshd, I am failing to
> understand how the service would check the listening port, so now I
> feel like I am hitting a wall.
You seem to mix two things: binding to the port and the output from rc.d
'status' command. Binding to the port is done by SSH by the bind(2)
system call and if something is already listening on the given address,
the socket won't be bound, so SSH daemon terminates.
'status' (for the case of /etc/rc.d/sshd) deduces the status of the
service from it's pid file (variable pidfile) with the subroutine
check_pidfile. Look at /etc/rc.subr: 'status' is handled via
"run_rc_command status" that evaluates _pidcmd that sets $rc_pid. And
then $rc_pid it checked for being non-empty, and if emptiness found,
command
-
echo "${name} is not running."
-
is executed. It produces the result you're seeing.
So, I would say that the PR in question is somewhat false positive.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: SSH Problem
Corne,
Mon, Dec 22, 2008 at 11:22:07AM +0200, Corne Kotze wrote:
> Thank for the reply.
> Sorry for the ignorance, but I should have added this as well.
>
> I am running apart from other things, a secure ftp server on this box as
> well that chroot the users to their home directories.
>
> I got the setup information from the following link:
> http://www.bsdguides.org/guides/freebsd/security/sftp_chroot_users.php
Ahm, SSH.com's realization of SSH suite. Forgot about this, sorry.
I had never used it, so can't say how to make it work with public key
authentication. But read on ;))
However, OpenSSH had gained the chroot ability in February 2008,
http://undeadly.org/cgi?action=article&sid=20080220110039
But if you're running 6.x, you won't be able to use it -- it was
imported only to 7.x and -CURRENT,
SVN rev 182634 on 2008-09-01 20:03:13Z by des
Though, no hope is lost -- security/openssh-portable is at 5.0p1, and
chroot support is there. But it is prone to the X11 MITM attack (at
least on HP/UX, don't currently know is FreeBSD is affected),
http://www.openssh.com/txt/release-5.1
Your mileage may vary, if, for example, you're not using X11 forwarding,
then you might be fine with this.
> Setting the "rc.conf" file to:
> sshd_enable="YES"
> sshd2_enable="NO"
>
> Then my sftp setup does not work properly, unless I am missing something
> that I can set in the "/etc/ssh/sshd_config" file.
Ooookey, if you still prefer SSH.com's software, you may find the following
article very enlightening,
http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Public-Key_Authentication-2.html
At least for me it looks very sane and verbose.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpSyh4FWyhYp.pgp
Description: PGP signature
Re: SSH Problem
Corne, good day.
Mon, Dec 22, 2008 at 10:22:39AM +0200, Corne Kotze wrote:
> The issue I have, hope somebody can help me, is with ssh security keys,
> no matter if I use RSA or DSA keys with or without passwords, I still
> have to login with a password to my FreeBSD server.
> It is between a Linux server(Client server) and my FreeBSD server.
>
> My setups are as follows:
> >From client server:
> Linux nagios-server 2.6.23-hardened-r4 #1 SMP
> OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007
>
>
> To FreeBSD server:
> FreeBSD secure-server 6.1-RELEASE-p17 FreeBSD 6.1-RELEASE-p17 #0: Fri
> May 25 19:54:30 IST 2007
> r...@secure-server:/usr/obj/usr/src/sys/SECURESRV-SMP i386
> OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004
>
> In my "/etc/rc.conf":
> sshd_enable="NO"
> sshd2_enable="YES"
There is no 'sshd2_enable' knob, there is only 'sshd_enable' one.
The protocols (and other stuff) are configured in /etc/ssh/sshd_config.
> I have tried the public key in various directories, in the users home
> directory, ie.
> .ssh/authorized_keys
> .ssh/authorized_keys2
>
> .ssh2/authorized_keys
> .ssh2/authorized_keys2
This is also governed by host's sshd_config: by-default, .ssh/authorized_keys
are used:
-
AuthorizedKeysFile .ssh/authorized_keys
-
> Permissions are set to 700 for the .ssh(2) directories and 600 for the
> authorized_keys(2) files.
That's fine.
> User and group access are also correct, and connection from the client
> machine is also with the correct user.
> If I change to the following in my "/etc/rc.conf" file:
> sshd_enable="YES"
> sshd2_enable="NO"
>
> Restart sshd, the keys work fine, no issues, I connect 100% without
> having to type any passwords.
Yes, it is expected. Forget about sshd2_enable -- 'man sshd_config' is
your friend. And if you're trying to enable only SSHv2, then the
default configuration of OpenSSH should be fine to you -- it allows only
v2 since ages. For your 6.1 only v2 should allowed by-default, but you
can explicitely state it in /etc/ssh/sshd_config, just to be sure.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpTaZXmmeWw6.pgp
Description: PGP signature
Re: memtest86+ on freebsd
Andriy, good day.
Mon, Dec 15, 2008 at 02:08:15PM +0200, Andriy Gapon wrote:
> on 12/12/2008 13:17 Andriy Gapon said the following:
> > Just in case anybody still remembers this issue.
> > It seams that the main culprit here was the following line in the linker
> > script:
> >
> > OUTPUT_FORMAT("elf32-i386");
> >
> > I was tipped just today that it should have read:
> > OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd",
> > "elf32-i386-freebsd");
>
> In fact it was Stephan Eisvogel who provided me with this hint.
Yes, it is a somewhat known culprit. A number of packages that are
messing with assembly code have troubles due to this directive. The
better way to overcome this issue is not to patch linker scripts, but to
override object format via '--oformat elf32-i386-freebsd' command-line
switch to ld(1). With this your proposed patch could be made even
smaller, providing that you can override linker command-line switches,
and it will be more robust in respect to the patching troubles when
linker scripts will be changed.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpzpCdWIJURI.pgp
Description: PGP signature
Re: FreeBSD
Wed, Dec 10, 2008 at 04:17:48AM +0200, Юлия Смолик wrote:
> Hello dear command of developers of FreeBSD. I wish to take part in the
> project on developing out of FreeBSD and to subscribe for dispatch.
http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026566.html
and especially http://www.freebsd.org/projects/index.html
http://wiki.freebsd.org/ will be good too.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpttDgtKl9rD.pgp
Description: PGP signature
Re: RFC: small syscons and kbd patch
Garret,
Fri, Dec 05, 2008 at 12:50:38AM -0800, Garrett Cooper wrote:
> 1. What dialect of C was it defined in? Is it still used in the
> standard dialect (honestly, this is the first time I've ever seen it
> before, but then again I am a younger generation user)?
It is the standard negation operator: !(expr) is equal to (expr == 0).
> 2. Is it still taught in schools (I didn't learn it when I was taught
> C)?
Yes. I am personally teaching the people in school and I am explaining
the concept of double negation every two years ;))
> If not in schools, what about the Richie text (it's sort of like
> the defacto C programming standard book of course)?
K&R book is good but it at no means covers all tricks and idioms
of a C language.
> 3. What's the real loss of going to `? :', beyond maybe 3 extra
> keystrokes if it's easier for folks who may not be as experienced to
> read?
No real loss, just easier to type and looks more compact. It is the
matter of a personal taste, I think.
If one knows this idiom, he will recognize it at a glance. If not, one
should think a bit about the logics behind it, but it shouldn't be hard:
almost everyone uses constructs like 'if (!ptr)'. And there is only one
step from there to the double negation.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpsI9cudOk9G.pgp
Description: PGP signature
Re: keeping track of local modifications
jT, good day.
Tue, Dec 02, 2008 at 07:15:55PM -0500, jT wrote:
> On Tue, Dec 2, 2008 at 6:52 AM, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> > The fact that `$FreeBSD$' is extracted in unexpanded form by the current
> > svn->hg converter is a limitation of the Python bindings of Subversion.
> > They do not support expansion of the svn:keywords property of checked
> > out files.
> >
>
>So am i to understand that there is no automatic way to use Hg or
> Git? -- and as Eygene said in order to use them in such a manner
> special patching will be required?
I am happily using Git for my FreeBSD work: I have local repository that
is just CVSupped from time to time to sync the master branch to the
mainline and, possibly, rebase my work against it. This isn't even
git-svn, just Git repo + CVSup. Probably git-svn will also work here,
but as ports are still using CVS and I have both ports and src
repositories, this is just easier for me to use CVSup. Yes, I am losing
the commit history, but I don't care about this: cvsweb.freebsd.org is
still alive and kicking.
About patching: the point was that some percentage of patches, that are
carrying '$FreeBSD$' tags in their body, won't apply cleanly in some
situations (namely, when your patch is based on the revision N and
maintainer applies it to the revision != N). It turns to be true even
for Subversion itself, but the hope isn't completely lost -- for some
cases patches can be applied with fuzz (namely, ignoring the '$Id'
mismatch). Larry Wall and others were smart about introducing the fuzz
factor ;))
> I too am looking to set something
> else up other than my SVN repository because i personally prefer Hg
> and Git to SVN. Thank you to all who have contributed to this
> conversation it has been extremely informative for me and i'm sure
> several others.
I think that you can at least try to work with git-svn: you'll check out
the master timely and will be able to rebase your own work, provided
that it is lying in the separate branches. This way you'll have the
whole history, at least you should.
Don't know for Mercurial, hadn't used it for FreeBSD yet.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpW7qBNX3UCB.pgp
Description: PGP signature
Re: Controlling a process
Maslan, good day.
Tue, Dec 02, 2008 at 09:53:09AM +, Maslan wrote:
> What is the best way to control a process (running in chroot env):
> 1- Execution time
> 2- Memory limit
> And to be able to kill the process when it breaks this limits.
man 2 setrlimit
> Finally, i would like to know the exit status of the process or the
> signal that killed it (sigfault, .)
If you're spawning the process in question, then 'man 2 wait'.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpSeBCIu43Om.pgp
Description: PGP signature
Re: keeping track of local modifications
Perry, good day.
Mon, Dec 01, 2008 at 09:08:25PM -0800, [EMAIL PROTECTED] wrote:
> > > Git and Mercurial cannot import Subversion $FreeBSD$ lines
> > > so far, and you may end up submitting patches that include
> > > unexpanded forms of the "$FreeBSD: $" text. These will
> > > fail to apply if they same patch touches nearby lines.
> >
> > Ahm, yes. "sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g'" should help
> > in this case.
>
> Not sure I understand what is meant by "unexpanded" here, since
> it looks as if this sed example would convert an "expanded" form
> -- containing the version info -- to an "unexpanded" one that
> merely shows where that info should go.
If you'll look at the diffs that are provided by Subversion, you'll
see that '$Id$' tags at the diff are shrinked to the '$Id' if keyword
expansion is enabled. For example,
-
Index: ChangeLog
===
--- ChangeLog (revision 40)
+++ ChangeLog (working copy)
@@ -1,4 +1,5 @@
$Id$
+add
Current version:
- Added CRL check for all certificates in chain during S/MIME
-
while original ChangeLog reads
-
$Id: ChangeLog 35 2008-04-11 10:02:37Z root $
add
Current version:
- Added CRL check for all certificates in chain during S/MIME
verification.
-
The above sed command will normalize $FreeBSD$ tags (de-expand them,
you're right that the wording was a bit ambigious).
But I was out of coffee yesterday, so I missed an important thing: such
diffs won't also apply, because you're really right: Subversion shrinks
'Id' (think 'FreeBSD') tags for diffs it is generating, but it has no
command 'svn patch' that will shrink these tags, apply the diff and
unshink them to the original form. And this matters when you're
generating the diff against version N, but maintainer applies it to the
version N + m. If I am correct, there is no simple automatic solution,
but special patching as described above will be needed.
Please, correct me if I am wrong.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpQpFu57wp8K.pgp
Description: PGP signature
Re: keeping track of local modifications
Giorgos, good day.
Mon, Dec 01, 2008 at 07:21:03PM +0200, Giorgos Keramidas wrote:
> On Mon, 1 Dec 2008 11:23:40 +0300, Eygene Ryabinkin <[EMAIL PROTECTED]> wrote:
> > May be I am missing something, but what's wrong with the patches from
> > other VCS, providing that with Subversion you can exchange only by the
> > plain diffs? Yes, Git/Mercurial patches should be applied with 'patch
> > -p1', but that's all. Subversion has no notion simular to 'git
> > format-patch' and 'git am', if I am not messing the things up, so the
> > only way to exchange with others are the patches themselves.
>
> Conflicts...
>
> Git and Mercurial cannot import Subversion $FreeBSD$ lines so far, and
> you may end up submitting patches that include unexpanded forms of the
> "$FreeBSD: $" text. These will fail to apply if they same patch
> touches nearby lines.
Ahm, yes. "sed -e's|$FreeBSD: [^$]* \$|$FreeBSD$|g'" should help
in this case.
Thanks for clarification!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpO62QVqPGS4.pgp
Description: PGP signature
Re: keeping track of local modifications
Max, good day.
Mon, Dec 01, 2008 at 08:30:16AM +0100, Max Laier wrote:
> On Monday 01 December 2008 07:07:00 [EMAIL PROTECTED] wrote:
> > * http://wiki.freebsd.org/LocalMercurial
> >
> > This seems less of a resource hog, and (if I am understanding
> > matters correctly) is able to start from the installed /usr/src/...
> > rather than requiring the would-be hacker to download a redundant
> > instance, but I was concerned that the page may not be up to date
> > with current FreeBSD development methodology (e.g. csup vs cvsup).
>
> If you want to contribute back, this is *not* the way to go. Patches from
> anything other than SVN and maybe CVS are mostly useless.
May be I am missing something, but what's wrong with the patches from
other VCS, providing that with Subversion you can exchange only by the
plain diffs? Yes, Git/Mercurial patches should be applied with 'patch
-p1', but that's all. Subversion has no notion simular to 'git
format-patch' and 'git am', if I am not messing the things up, so the
only way to exchange with others are the patches themselves.
> The local hg/git
> approach is nice if you are already familiar with hg or git and just want to
> keep some patch sets for yourself. If you are looking to keep/develop a patch
> set and eventually share it with the world, svn or svk is the way to go.
The only issue I do see is about '$FreeBSD$', but plain Subversion
clients shouldn't mess with it. If person has commit privileges to the
FreeBSD repository, then yes, probably Subversion will be fine (but
there are git-svn and hgsvn, so locally user can work with the different
VCS even in this case).
Do I missing some important thing here?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpSsbzOpdPqq.pgp
Description: PGP signature
Re: New C compiler and analyzer lang/cparser in ports
Christoph,
Thu, Nov 27, 2008 at 11:22:22PM +0100, Christoph Mallon wrote:
> Both LLVM and FIRM use SSA as an important aspect of their IR. FIRM uses
[...]
Very interesting, thanks for a good review!
> Did you find the frontend examples interesting or are you mainly
> interested in optimization and backend aspects?
Both ;)) Frontends for code generation and optimization/backends for
playing with their guts and learning interesting things.
Thanks again!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpUz6c0UAktg.pgp
Description: PGP signature
Re: New C compiler and analyzer lang/cparser in ports
Christoph, good day.
Thu, Nov 27, 2008 at 09:39:45PM +0100, Christoph Mallon wrote:
> A few days ago libFIRM[1] and cparser were added to the ports tree. If
> you want to see, what other compilers besides GCC have to offer, this
> might be of interest for you. libFIRM is a modern optimizing
> intermediate representation (IR) library. cparser is a C compiler
> providing many useful warnings and uses libFIRM for optimization and
> code generation.
[...]
The whole description looks like that of LLVM GCC port, http://llvm.org/
Do you know something about that project and if yes, could you, please,
provide brief comparison of these two?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpK8LNQ180Dn.pgp
Description: PGP signature
Re: assigning interrupts
Thu, Nov 13, 2008 at 06:03:20PM +0800, Ronnel P. Maglasang wrote:
> Is there a way to explicitly assign an interrupt
> of a device?
What about BIOS? What about physically reshuffling the cards
if they aren't on-board ones?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpRiwEw6XWSX.pgp
Description: PGP signature
Re: [Testers wanted] /dev/console cleanups
Ed, good day.
Tue, Oct 28, 2008 at 09:11:54AM +0100, Ed Schouten wrote:
> It's nice to hear that the patch didn't break anything on your system. I
> hope to receive more reviews, but I think I'll just commit it this
> weekend (with small modifications).
Just a quick "me too" message: patchset from October, 29th works
flawlessly on my systems.
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgp3Kf6n39Z2O.pgp
Description: PGP signature
Re: Usage of "files" for config
Srinivas, good day.
Tue, Oct 28, 2008 at 03:52:35AM +0530, Srinivas wrote:
> I would like to know the usage of files and files.[arch] in sys/conf.
> Basically, I didnt get the advantage of having a common file for
> compilation(like files) rather than an individual Makefile in each
> subdirectory.
'files' and 'files.$ARCH' are the input directives for the config(8)
utility. Makefile is produced with the help of these files. The
rationale for having 'files' and 'files.$ARCH' is simple: there are
platform-specific directives and common directives.
>
> I have read makefile(of mkmakefile.c in config). What is the usage of
> "standard", "optional" and "mandatory" and why it is followed by
> device.
Read comments from 'mkmakefile.c':
-
/*
* If an entry is marked "mandatory", config will abort if it's
* not called by a configuration line in the config file. Apart
* from this, the device is handled like one marked "optional".
*/
-
> What are .m files? What are they used for?
They define module interfaces and are processed by the AWK script
/sys/tools/makeobjops.awk. The output will be source and header files,
named .c and .h. You can do 'ls *_if.[ch]' in
the kernel build directory and examine some files to get a hint on
what's going on. M-files are processed with the help of
/sys/conf/kern.post.mk and /sys/conf/kmod.mk.
> Why are some of the rules in the generated makefile *.ln like scsi_all.ln?
These files are lint(1)'ed: see /sys/conf/kern.post.mk, search for
LNFILES.
> What is ${NORMAL_LINT} and ${NORMAL_C} in the generated makefile mean?
'make -V NORMAL_LINT' and 'make -V NORMAL_C' invoked from the kernel
compilation directory should tell you about the values of these
variables. They are defined by /sys/conf/kern.pre.mk, so you can
examine it as well.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpBOoMn3hgfL.pgp
Description: PGP signature
Re: HEADS UP: GCC 4.2.0 is coming
Good day.
Wed, Oct 08, 2008 at 07:57:51AM +, O. Hartmann wrote:
> Alexander Kabaev wrote:
> > On Fri, 18 May 2007 19:20:07 -0400
> > Alexander Kabaev <[EMAIL PROTECTED]> wrote:
> >
> >> HEADS UP: I will start importing GCC 4.2.0 bits in about one hour and
> >> plan to finish in a couple of hours after that.
> >>
> >> The src/ tree will be utterly broken meanwhile. I'll send an 'all
> >> clear' message when done.
> >
> > Done.
> >
>
> Just for those who aren't on the cutting edge: why gcc 4.2.0 and not
> 4.2.1 as it is used in 7.X?
It was the old message that slipped to the list due to some
misconfiguration of the mailing list software. Look at its
date -- it's more than one year old.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpneOlMFm6XD.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Forgot to say: Tue, Oct 07, 2008 at 12:30:58AM +0400, Eygene Ryabinkin wrote: > OK, I had implemented both '-o' option to pkg_audit and the usage of the > local INDEX file. The latter can be activated by writing something like - portaudit_pkg_index="file:///usr/ports/INDEX-%d" - to the /usr/local/etc/portaudit.conf. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Mon, Oct 06, 2008 at 02:30:29PM +0400, Eygene Ryabinkin wrote: > OK, fine. I will implement the usage of the local INDEX file in some > days. OK, I had implemented both '-o' option to pkg_audit and the usage of the local INDEX file. I had reworked pkg_audit and portaudit a bit further, mostly fixing some issues (both mine and existing). Here we go. Patches for pkg_install that adds pkg_audit: http://codelabs.ru/fbsd/patches/portaudit/0001-Add-functions-for-traversing-package-database-and-ma.patch http://codelabs.ru/fbsd/patches/portaudit/0002-Add-function-match_get_pkgorigin.patch http://codelabs.ru/fbsd/patches/portaudit/0003-New-utility-pkg_audit.patch http://codelabs.ru/fbsd/patches/portaudit/0004-pkg_audit-add-option-to-print-origins.patch Mega-patch for pkg_install: http://codelabs.ru/fbsd/patches/portaudit/pkg_install-megapatch-pkg_audit.diff Patches for portaudit: http://codelabs.ru/fbsd/patches/portaudit/0001-Avoid-usage-of-global-variables-N-in-the-print_affe.patch http://codelabs.ru/fbsd/patches/portaudit/0002-Separate-vulnerable-ports-search-from-the-formatter.patch http://codelabs.ru/fbsd/patches/portaudit/0003-Use-pkg_audit-utility-if-it-is-available.patch http://codelabs.ru/fbsd/patches/portaudit/0004-Implement-checking-for-a-new-package-versions.patch Mega-patch for portaudit: http://codelabs.ru/fbsd/patches/portaudit/portaudit-megapatch_pkg_audit-and-checknew.diff Opinions are welcome! -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Mel,
Mon, Oct 06, 2008 at 02:40:48PM +0200, Mel wrote:
> What I meant is the '-o' flag in pkg_audit, so I can figure out myself whether
> it's new or not and my buildserver can prioritize it's builds based on
> vulnerable packages it's clients have installed. The origin is the unique key
> that identifies any port, so that's vital information in a pipeline.
Ah, OK: no problems, will do it.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpSGQDFsHpGv.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Mel,
Mon, Oct 06, 2008 at 01:07:51PM +0200, Mel wrote:
> On Monday 06 October 2008 12:28:48 Eygene Ryabinkin wrote:
> Once you have the origin of the port, you can:
> - make -C $PORTSDIR/$origin -V PKGNAME
> - get the matching origin(s) out of ${INDEXDIR}/${INDEXFILE}
> - get the matching origin(s) out of a downloaded INDEX.bz2
>
> This covers the majority of cases.
>
> What portaudit lacks, is providing the origin along with the installed package
> name in easily parseable format. So, a central server wanting to query all
> the machines for vulnerable packages, now has to do an extra step of going
> into $PKG_DBDIR/$pkgname/+CONTENTS and getting the @comment ORIGIN: line,
> while (port|pkg_)audit has just been there.
>
> This would be something I'd expect:
> ssh clientmachine "/usr/sbin/pkg_audit -l"
> foo-1.2,3:misc/foo
> bar-4.5_6:devel/bar
> ...
OK, got it. There is one neat: pkg_audit should be feeded with the
contents of the auditfile and the latter is located in the tar archive.
So, if you wouldn't mind about the following sequence
-
tar xf /var/db/portaudit/auditfile.tbz
pkg_audit < auditfile | portaudit-checknew -o | cut -d '|' -f1,4,5
-
then I can add the flag '-o' to the portaudit-checknew: it will
additionally output the port origin along with the new version.
Is that what you meant?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpnTKHygtKTG.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Miroslav,
Mon, Oct 06, 2008 at 10:59:46AM +0200, Miroslav Lachman wrote:
> I have '/usr/sbin/portsnap cron' and '/usr/sbin/portsnap -I update' in
> my crontab, so I get INDEX updated every night before nightly security
> e-mail is generated.
Ah, I see. Thanks!
> > But downloading the INDEX file from the central server seemed to be the
> > best way, since it almost always gives one the latest port versions, so
> > I had implemented this in a first place.
>
> My previous question was not against your solution, it seems useful to
> have really actual data from the fresh INDEX. It was just a question
> "how it is done". Maybe someone will be happier to use the existing
> INDEX because of traffic on some GPRS internet connection or because of
> the own INDEX creation. (it is not my case, I have all machines as the
> servers with enough connectivity) ;)
OK, fine. I will implement the usage of the local INDEX file in some
days.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpP3tHxQnKof.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Mel, good day.
Mon, Oct 06, 2008 at 11:24:54AM +0200, Mel wrote:
> On Monday 06 October 2008 07:23:37 Eygene Ryabinkin wrote:
> > But downloading the INDEX file from the central server seemed to be the
> > best way, since it almost always gives one the latest port versions, so
> > I had implemented this in a first place.
>
> I've been following this, but I don't agree that (port|pkg_)audit should do
> this, from the very perspective you're writing this program from:
The download is done not by the portaudit itself, but by the helper
script, portaudit-checknew.
> On Sunday 28 September 2008 11:49:18 Eygene Ryabinkin wrote:
> > 4. I feel that it is Unix-way to do the things: create small utilities
> >that do their (small) job in a proper fashion.
>
> Instead, it can provide installed-pkgnamepkgorigin output. Then,
> any utility can check whether a new version is available, using what ever
> source it finds relevant.
>
> For example, it is completely irrelevant if a new version is available on the
> FreeBSD servers, when your machine uses a buildserver in a local network. For
> those machines it's relevant whether their build server has a new version and
> one can automatically upgrade if one so desires.
> Similarly, if your /usr/ports is ahead of the FreeBSD's INDEX.bz2, you're
> again reporting false information.
I hear you, but it seems to me that I should just equip
portaudit-checknew with the other sources of a new ports information and
provide tunables for their location (on-disk path, URL, etc). I am
planning to do this, but first I want to know if these patches will be
viable for the project: feeding these into the /dev/null or just using
them locally, but equipping with a lot of functionality, is not what I
really want ;))
> It's also quite trivial to provide this availibility information in a daily
> security script, for the "majority of cases"
Didn't get it, sorry. Could you, please, elaborate a bit?
> and it's better to have tunables
> like _use_remote_portindex, _use_portsdir=/bigdisk/usr/ports in a script.
Yes, it was what I had talked about above in this mail.
Thanks for the input!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpLvYTrbprI1.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Miroslav, good day.
Mon, Oct 06, 2008 at 12:41:05AM +0200, Miroslav Lachman wrote:
> I am busy these days, but it is nice to read about your progress. I hope
> I will get some time to test all of these large patches in a few days
> and I will report back my experiences!
Fine, thank you! I am re-CC'ing bug-followup@ to track this letter,
since it contains some useful information that should go into GNATS.
> One note before tests... do -n flag always download new INDEX file, or
> is it possible to use one already existing in /usr/ports?
Currently, it is downloads bzipped INDEX file to /var/db/portaudit every
time, but it uses mirror mode, so if remote file hadn't changed at all,
all network expences are just the HTTP's HEAD request and reply.
I can add another variable to the portaudit to force the usage of the
existing INDEX file, if it is needed. By the way, how are you keeping
your INDEX file up to date (your proposed usage of 'pkg_version -I'
implies that you're always rely on it)? I am just curious -- my INDEX
files are almost always stay unupdated, even if I am using portupgrade.
And there can be another way if one keeps ports tree updated: utility
can use 'make' to determine the version that is currently available on
the examined host.
But downloading the INDEX file from the central server seemed to be the
best way, since it almost always gives one the latest port versions, so
I had implemented this in a first place.
Don't know, however, how the badly the load to the central HTTP server
will be raised. I am using just two first fields from the INDEX file,
so I can use such a stripped file. For me, the reduction was about
6x: SIZE(INDEX-7.bz2) = 1126189, SIZE(INDEX-7.stripped.bz2) = 184345.
I am CC'ing the portmgr team. Guys, could you quickly glance over these
patches and determine if they are useful to the project in large? If
yes, then may be such a stripped INDEX can be created on the FreeBSD
servers (via cut -f1-2 -d'|' INDEX-N)?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpuIHJV2rxQv.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Sun, Oct 05, 2008 at 11:03:17PM +0400, Eygene Ryabinkin wrote:
> I had also changed the output format for pkg_audit, so I am attaching
> another version of the second patch for the pkg_install bundle.
One neat about new pkg_audit utility: if you already have the build
directory for pkg_install in the /usr/obj, you should create
subdirectory for the pkg_audit,
-
mkdir /usr/obj/usr/src/usr.sbin/pkg_install/audit
-
or completely remove /usr/obj/usr/src/usr.sbin/pkg_install
World build should do it automatically, at least it worked for me.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpHaQ8j5yDeQ.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Miroslav, good day.
Sun, Sep 28, 2008 at 04:14:24PM +0400, Eygene Ryabinkin wrote:
> > If I read nightly security e-mail with for example 4 vulnerable
> > packages, then I need to log in to server and manualy try, if newer
> > (fixed) packages are available. It seems not so hard to check output of
> > `pkg_version -vIL =` and compare both versions (installed and available)
> > with portaudit in some shellscript, I didn't start to write it yet ;).
>
> I think it won't be very hard: I'll try to see how to extend portaudit
> with such functionality -- it would be very handy, in my opinion.
OK, I extended portaudit with this -- flag '-n' will do it. Currently
this option requires network access, but I think that it is perfectly
fits into the security check -- it downloads auditfile anyway.
I had greatly reworked the old part of patch and I have series of
4 patches that implement both my pkg_audit stuff and the '-n' stuff.
I am also attaching the mega-patch, it can be applied to the current
port sources to give the port version that includes both mentioned
enchancements. If you have no pkg_audit -- this isn't a problem:
portaudit fill fall back to the awk script.
I had also changed the output format for pkg_audit, so I am attaching
another version of the second patch for the pkg_install bundle.
I had briefly tested my modifications -- they work for now, but I will
continue testing. Any bug reports or thoughts about these patches are
more that welcome.
> Hadn't you have a chance to test my patch?
Miroslav, still: had you tested the pkg_audit thingy?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
From 88a3659c2d941e27de698fe05e4852a9f418f16e Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin <[EMAIL PROTECTED]>
Date: Tue, 26 Aug 2008 15:08:46 +0400
Subject: [PATCH] New utility: pkg_audit
It is mainly a helper for portupgrade to avoid awk scripting and
numerous calls for pkg_info. This utility speeds up portaudit by a
factor of 10 on a system with 521 installed ports and the auditfile that
contains 3213 entries:
-
$ ls -d /var/db/pkg/* | wc -l
521
$ tar xOf /var/db/portaudit/auditfile.tbz auditfile | sed -e'/^#/d' | wc -l
3213
$ time ./portaudit
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- DNS spoofing vulnerability.
Reference: <http://www.FreeBSD.org/ports/portaudit/959d384d-6b59-11dd-9d79-001fc61c2a55.html>
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- DoS vulnerability in WEBrick.
Reference: <http://www.FreeBSD.org/ports/portaudit/f7ba20aa-6b5a-11dd-9d79-001fc61c2a55.html>
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- multiple vulnerabilities in safe level.
Reference: <http://www.FreeBSD.org/ports/portaudit/c329712a-6b5b-11dd-9d79-001fc61c2a55.html>
3 problem(s) in your installed packages found.
You are advised to update or deinstall the affected package(s) immediately.
real0m0.107s
user0m0.116s
sys 0m0.012s
$ time portaudit
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- multiple vulnerabilities in safe level.
Reference: <http://www.FreeBSD.org/ports/portaudit/c329712a-6b5b-11dd-9d79-001fc61c2a55.html>
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- DoS vulnerability in WEBrick.
Reference: <http://www.FreeBSD.org/ports/portaudit/f7ba20aa-6b5a-11dd-9d79-001fc61c2a55.html>
Affected package: ruby-1.8.6.111_4,1
Type of problem: ruby -- DNS spoofing vulnerability.
Reference: <http://www.FreeBSD.org/ports/portaudit/959d384d-6b59-11dd-9d79-001fc61c2a55.html>
3 problem(s) in your installed packages found.
You are advised to update or deinstall the affected package(s) immediately.
real0m1.583s
user0m0.560s
sys 0m1.057s
-
Signed-off-by: Eygene Ryabinkin <[EMAIL PROTECTED]>
---
Makefile |2 +-
audit/Makefile| 14 +++
audit/audit.h | 43 +
audit/main.c | 166 ++
audit/parse.c | 259 +
audit/pkg_audit.1 | 63 +
6 files changed, 546 insertions(+), 1 deletions(-)
create mode 100644 audit/Makefile
create mode 100644 audit/audit.h
create mode 100644 audit/main.c
create mode 100644 audit/parse.c
create mode 100644 audit/pkg_audit.1
diff --git a/Makefile b/Makefile
index fefbd08..abc1e65 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
.include
-SUBDIR= lib add create d
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Miroslav, good day.
Sun, Sep 28, 2008 at 01:15:01PM +0200, Miroslav Lachman wrote:
> Is there any possibility to cooperate portaudit / pkg_audit with
> pkg_version to show vulnerable package with information if newer (not
> vulnerable) package (or port) version is available for upgrade to?
>
> If I read nightly security e-mail with for example 4 vulnerable
> packages, then I need to log in to server and manualy try, if newer
> (fixed) packages are available. It seems not so hard to check output of
> `pkg_version -vIL =` and compare both versions (installed and available)
> with portaudit in some shellscript, I didn't start to write it yet ;).
I think it won't be very hard: I'll try to see how to extend portaudit
with such functionality -- it would be very handy, in my opinion.
Hadn't you have a chance to test my patch?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpT8Y0bE7cmY.pgp
Description: PGP signature
Re: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Roman, good day.
Sat, Sep 27, 2008 at 08:18:08PM +0400, Roman Kurakin wrote:
> Have you also posted this to [EMAIL PROTECTED]
No, forgot to do it. CC'ing ports@
Thanks!
The original posting to hackers@ goes below. It will be double-posted
to the bug-followup@ -- sorry for this.
> Eygene Ryabinkin wrote:
> > Good day.
> >
> > A while ago I had created the new utility that serves as VuXML
> > filter for the installed packages:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126853
> >
> > My primary intention was to speed up the process of auditing the
> > vulnerable ports: I needed to run portaudit checks with Nagios and to
> > avoid large timeouts.
> >
> > The new utility is called pkg_audit and it serves as a simple text
> > filter: on input it takes the full VuXML feed and on output it puts
> > VuXML entries that matches ports that are installed in the system with
> > port version specification substituted with the actual port versions.
> >
> > No harm is done to the actual poartudit -- if pkg_audit is missing, old
> > code path is activated.
> >
> > If someone is interested and will be able to test -- I am all ears.
Additional clarifications inspired by the off-line talk with rik@:
I could take another route and add this functionality to the pkg_info.
I took another approach for the following reasons.
1. pkg_info's option list is already quite big -- around 32 options
and switches.
2. It is easier to test for the presence of the new tool (pkg_audit)
and use it, instead of checking the support for the new option in
pkg_info.
3. I see no options in pkg_info that can be naturally extended to
absorbe the new functionality. The closest is '-E', but pkg_audit
needs to read VuXML entries, choose ones that are present in the system
and output the found VuXML entries with version templates substituted
with the real entries, so pkg_audit is filter-like utility. In my
opinion, such extension of pkg_info's "-E" will be very unnatural.
4. I feel that it is Unix-way to do the things: create small utilities
that do their (small) job in a proper fashion. Moreover, since the
majority of a code sits in the pkg_install's library, there is a very
slight code duplication, if any.
Thanks for you time.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpoPUf5tBrSR.pgp
Description: PGP signature
Re: Problem Protecting Directories Securly
Mike, good day.
Sat, Sep 27, 2008 at 06:45:11PM -0700, Mike Price wrote:
> My buddy helped me install Apache Webserver but there is somthing wrong when
> I try to password protect my directories? I already created '.htaccess' &
> 'htpasswd' and but I still cannot password protect the directory... I know
> there is a command to do this 'htpasswd -c .htpasswd' fred but it dosn't
> work.
It is certainly not the question for freebsd-hackers, but it should
rather go to some Apache-related list, perhaps Apache-hosted lists
themselves. See http://httpd.apache.org/userslist.html
And try not to miss the link named "Asking Questions the Smart Way"
on the above mentioned page -- it is a good reading.
To the point: you can be interested in two links, depending on your
Apache version:
http://httpd.apache.org/docs/1.3/howto/auth.html
http://httpd.apache.org/docs/2.2/howto/auth.html
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpgej8yk0ZJn.pgp
Description: PGP signature
ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Good day.
A while ago I had created the new utility that serves as VuXML
filter for the installed packages:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126853
My primary intention was to speed up the process of auditing the
vulnerable ports: I needed to run portaudit checks with Nagios and to
avoid large timeouts.
The new utility is called pkg_audit and it serves as a simple text
filter: on input it takes the full VuXML feed and on output it puts
VuXML entries that matches ports that are installed in the system with
port version specification substituted with the actual port versions.
No harm is done to the actual poartudit -- if pkg_audit is missing, old
code path is activated.
If someone is interested and will be able to test -- I am all ears.
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgphOb5l21SUP.pgp
Description: PGP signature
Re: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c
Me again.
Thu, Sep 18, 2008 at 11:10:17AM +0400, Eygene Ryabinkin wrote:
> OK, I had tried substituting KBDMUX_LOCK/UNLOCK with Giant operations --
> it works as expected.
Tried my initial patch on some 7.0-PRERELEASE -- it locks keyboard when
geli asks for the password. Had not much time to dig it out, will try
to do it as soon as I can. Substituting KBDMUX_LOCK/UNLOCK with Giant
locking helps even on this FreeBSD version.
More testing needed, may be there are some other issues that aren't
revealing themselves...
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgpFLJHKtzyvp.pgp
Description: PGP signature
Re: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c
Maksim, good day.
Wed, Sep 17, 2008 at 10:52:15AM -0700, Maksim Yevmenkin wrote:
> yes, giant is recursive. i think it should be fine for now (and yes, i
> agree, its not very clean)
OK, I had tried substituting KBDMUX_LOCK/UNLOCK with Giant operations --
it works as expected. I am sligtly concerned with the fact that, for
example, kbdmux_kbd_event() will grab Giant for some more time than the
initial version that protects only polling loop.
Probably it is not a big concern: the call chain from syscons's cngetc()
(via cncheckc(), syscons->cn_getc() == sc_cngetc(), sccngetch(),
scgetc() and kbd_read_char()) to the kbdmux_read_char() is the only code
path that is not protected by Giant, being called from the kernel
directly:
- user-level code is notified about key presses by syscons that signals
tty layer about key press from sckbdevent();
- no other kbdmux routine seem to be called without being
Giant-protected (at least, I see no parts that can race with the
low-level keyboard events).
So the typical overhead of mangling with Giant at KBDMUX_{LOCK,UNLOCK}
is only in extra calls to the _mtx_lock_flags/_mtx_unlock_flags. The
only extra code that will hold Giant for a longer time is the kernel's
interactive input routines, but their performance is user-bounded ;))
There is one interesting question: I assume that clock interrupts are
lost when Giant is hold? If so, then holding Giant for some extra time
upon system's initialization when kernel waits for user input will
enable the system to drop bigger amounts of clock interrupts -- I assume
that the code in kbdmux_read_char() that translates the scancode takes
the biggest amount of run-time compared to the polling loop. Sure, the
overhead will be added just for the typed characters -- when there is no
input, overhead is rather small.
May be this will not lead to any bad (or visible/measurable)
consequences -- can't tell now.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgp3cqxRZ3TzQ.pgp
Description: PGP signature
Re: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c
Maxim, good day.
Cc'ing this discuission to hackers@ -- I was just going to write
the separate letter on this topic to the list.
Wed, Sep 17, 2008 at 09:56:14AM -0700, Maksim Yevmenkin wrote:
> have you tried to simply set KBDMUX_LOCK/UNLOCK() to
> mtx_lock/unlock(&Giant) ?
Since kbdmux callout is initialized as non-MPSAFE, this will result in
double locking the Giant (at least I see it from the code). I am not
sure that this is very good -- had not yet verified that Giant is
recursive.
Can try it tomorrow.
Since you had written the code and #if 0'ed the locking part, may I ask,
why? Are there any known issues or it was just not very good to
introduce locking at that time (rev. 1.1, 3 years ago)?
Thanks!
> On Wed, Sep 17, 2008 at 9:16 AM, Eygene Ryabinkin <[EMAIL PROTECTED]> wrote:
> >>Number: 127446
> >>Category: kern
> >>Synopsis: [patch] fix race in sys/dev/kbdmux/kbdmux.c
> >>Confidential: no
> >>Severity: critical
> >>Priority: high
> >>Responsible:freebsd-bugs
> >>State: open
> >>Quarter:
> >>Keywords:
> >>Date-Required:
> >>Class: sw-bug
> >>Submitter-Id: current-users
> >>Arrival-Date: Wed Sep 17 16:20:02 UTC 2008
> >>Closed-Date:
> >>Last-Modified:
> >>Originator: Eygene Ryabinkin
> >>Release:FreeBSD 7.1-PRERELEASE amd64
> >>Organization:
> > Code Labs
> >>Environment:
> >
> > System: FreeBSD XXX 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #55: Wed Sep 17
> > 19:57:25 MSD 2008 [EMAIL PROTECTED]:/usr/src/sys/amd64/compile/XXX amd64
> >
> > CVSupped system yesterday late at the evening (aroung 17:00 UTC).
> >
> >>Description:
> >
> > Since kbdmux(4) is not MPSAFE now, its interrupt routines are running
> > under Giant. But there is kbdmux_read_char() routine that runs unlocked
> > and can race with the interrupt handler. When there is no input data
> > in the keyboard queue and kbdmux(4) is in the POLLING mode, routine will
> > try to poll each mux member for the scancode. And if user presses the
> > key at that time, KBDMUX_READ_CHAR() can race with the interrupt handler
> > kbdmux_kbd_event() since we don't lock polling loop.
> >
> >>How-To-Repeat:
> >
> > I see this on my laptop: sometimes during boot, when system asks me for
> > the password of geli(8)-encrypted volume, it doubles the symbols or even
> > panics. I don't see this on the other systems, so perhaps my laptop is
> > just so lucky ;))
> >
> > But one can try to enable echoing of the input symbols during the geli's
> > bootup password dialog (setting g_eli_visible_passphrase to 1
> > unconditionally) and maybe symbols will be doubled. I see this issue
> > only during boot-up phase, but I feel that this is due to the fact that
> > for the rest of the system's operation only interrupt handler is
> > working, at least I see it from the debug printf()s.
> >
> >>Fix:
> >
> > The following patch fixes the things for me. It just acquires Giant for
> > the time of polling. I did a limited testing at my systems and there
> > were no signs of regressions yet.
> >
> > Seems like in the properly locked situation (with non-dummy KBDMUX_LOCK
> > and KBDMUX_UNLOCK) this issue will vanish, so I had conditionalized
> > Giant grabbing.
> >
> > --- kbdmux-read-race.patch begins here ---
> > --- sys/dev/kbdmux/kbdmux.c.orig2008-09-17 10:41:00.0 +0400
> > +++ sys/dev/kbdmux/kbdmux.c 2008-09-17 19:52:00.0 +0400
> > @@ -79,6 +79,10 @@
> > */
> >
> > #if 0 /* not yet */
> > +#define KBDMUX_LOCK_POLLER(dummy)
> > +
> > +#define KBDMUX_UNLOCK_POLLER(dummy)
> > +
> > #define KBDMUX_LOCK_DECL_GLOBAL \
> >struct mtx ks_lock
> > #define KBDMUX_LOCK_INIT(s) \
> > @@ -98,6 +102,10 @@
> > #define KBDMUX_QUEUE_INTR(s) \
> >taskqueue_enqueue(taskqueue_swi_giant, &(s)->ks_task)
> > #else
> > +#defineKBDMUX_LOCK_POLLER(dummy) \
> > + mtx_lock(&Giant)
> > +#defineKBDMUX_UNLOCK_POLLER(dummy) \
> > + mtx_unlock(&Giant)
> > #define KBDMUX_LOCK_DECL_GLOBAL
> >
> > #define KBDMUX_LOCK_INIT(s)
> > @@ -661,6 +669,14 @@
> >if (state->ks_flags & POLLING) {
> >kbdmux_kbd_t*k;
> >
> > + /*
> > +* Grab Giant: we don't want to
Re: git problems
Dmitry, good day.
Wed, Jun 04, 2008 at 11:21:59PM +0400, Chagin Dmitry wrote:
> this problem with git is fixed in version 1.5.5.1,
Yeah, commit 7b7f39eae6ab0bbcc68d3c42a5b23595880e528f
> our port requires updating.
Care to test? The diff from 1.5.5 is below. Ed, Eric, anyone, any
comments? I had tested packaging list -- it seems to be unchanged
since 1.5.5, both for the cases of GUI and GUI-less git. And no
new functionality was brought in, judging by ChangeLog contents
and quick glance over commits.
-
diff -urN ./Makefile ../git/Makefile
--- ./Makefile 2008-06-04 23:52:50.0 +0400
+++ ../git/Makefile 2008-06-04 23:53:38.0 +0400
@@ -6,7 +6,7 @@
#
PORTNAME= git
-PORTVERSION= 1.5.5
+PORTVERSION= 1.5.5.3
CATEGORIES=devel
MASTER_SITES= http://www.kernel.org/pub/software/scm/git/
DISTFILES= ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX} \
diff -urN ./distinfo ../git/distinfo
--- ./distinfo 2008-06-04 23:52:50.0 +0400
+++ ../git/distinfo 2008-06-04 23:58:08.0 +0400
@@ -1,6 +1,6 @@
-MD5 (git-1.5.5.tar.bz2) = 09f15f0b0e330986d930746abf6962f4
-SHA256 (git-1.5.5.tar.bz2) =
27483890c598450d7d1b4583e40dd8ec6c8def08c7cec94b20eb7336bb83e65e
-SIZE (git-1.5.5.tar.bz2) = 1673736
-MD5 (git-manpages-1.5.5.tar.bz2) = 62a82276856add1d2b310d1e0b5ad5db
-SHA256 (git-manpages-1.5.5.tar.bz2) =
cc7f16b72a228cafd6bcc41ea09fdc67f4c5d50a0bf4521b80d8ea75127bb802
-SIZE (git-manpages-1.5.5.tar.bz2) = 162609
+SIZE (git-1.5.5.tar.bz2) = 1677113
+MD5 (git-1.5.5.3.tar.bz2) = 022ce5772b900243ef5d289deb7a3667
+SHA256 (git-1.5.5.3.tar.bz2) =
c0a5220e7c80dc791e2077ec238298c2ec30af4d8d0ed6d2fbd7ca808266dfc0
+MD5 (git-manpages-1.5.5.3.tar.bz2) = 374a62ddf37343a5130f3318eab1ce2b
+SHA256 (git-manpages-1.5.5.3.tar.bz2) =
770543b0ca871f72829f810d51f9e4d8b27659cbf4e73534fd09dfb5833f99de
+SIZE (git-manpages-1.5.5.tar.bz2) = 163895
-
Perhaps this topic should now be moved out of -hackers.
--
Eygene
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
Chuck,
Wed, Jun 04, 2008 at 11:26:02AM -0400, Chuck Robey wrote:
[...]
> Looking at the top stack frame (main), that frame and the next are deeply
> involved in inspecting argv 0 thru 2, and since it's full of garbage, that's
> what breaks things. That's NOT malloc, that seems to be either a problem in
> process creation or (I think more likely) a problem in the creation of a
> process's environment, the crt0 stuff. I'm getting out of my depth, here.
Sorry, I had thought about stack smashing, but it isn't it, so I
somewhat guided people to the wrong way (if they were listening to me ;))
The real problem was the doubled call to the transport_unlock_pack()
in the builtin-fetch.c. And the stack frame with __cxa_finalize
was perfectly correct -- as I learned half an hour ago, it is the
function that calls all handlers, registered with atexit().
So, the problem was the following: static function unlock_pack()
in the builtin-fetch.c is the cleanup routine for the static variable
'transport'. And it calls transport_unlock_pack() if the 'transport'
variable isn't NULL. But do_fetch() calls free(transport), so
atexit's unlock_pack() tries to use already freed memory.
The below patch works for me, although I should think about it
once more to see if it handles all cases. Please, try the patch.
--- builtin-fetch.c.orig2008-06-04 22:49:05.0 +0400
+++ builtin-fetch.c 2008-06-04 23:07:51.0 +0400
@@ -598,7 +598,7 @@
int cmd_fetch(int argc, const char **argv, const char *prefix)
{
struct remote *remote;
- int i;
+ int i, retval;
static const char **refs = NULL;
int ref_nr = 0;
@@ -654,6 +654,14 @@
signal(SIGINT, unlock_pack_on_signal);
atexit(unlock_pack);
- return do_fetch(transport,
+ retval = do_fetch(transport,
parse_fetch_refspec(ref_nr, refs), ref_nr);
+ /*
+* Set transport to NULL, because its contents are already
+* freed in do_fetch(), so we mustn't deinitialize it in
+* unlock_pack().
+*/
+ transport = NULL;
+
+ return retval;
}
--
Eygene
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: git problems
Chuck, Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote: > > Any possibility of using ElectricFence (devel/ElectricFence) > > for chasing memory-related troubles? > > Now that I have gdb working with me again, I am checking the git-fetch image > to > see where it got lost. If I must bring a tool such as ElectricFence I, I > guess > I must, just I'm a bit irritated that the git build has one of those make > "improvements" (NOT) that instead of telling you the buid line, just gives you > "CC sourcename.c" which for anyone who knows code is just irritating, not any > sort of help at all. No problems, just issue 'make V=1' instead of just 'make' in the /devel/git -- it will give you all flags and will eliminate the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized binary with debug symbols that can be directly traced by gdb with all symbols and right (unoptimized, as in the sources) code paths. For the ElectricFence -- it dumps core just after startup, I don't know why. So it is not very much usable now, at least for me. Thank you. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
Chuck,
Wed, Jun 04, 2008 at 10:12:55AM -0400, Chuck Robey wrote:
> >> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace
> >> nearby, but it seems to be crash inside free().
> >
> > Application memory errors in HEAD but not in a RELENG_ branch are
> > frequently a symptom of an application bug unmasked by malloc(3)
> > debugging enabled in the development branch but not production
> > branches. It might not hurt to ramp up debugging on your 6.x install to
> > see if it starts crashing there was well -- see malloc(3) for details,
> > you'll want to create an appropriate malloc.conf.
>
> I didn't see the email where Ed Schouten commented about seeing my problems of
> seeing no good stack frames, but Robert, I run only -current here, not
> RELENG_6,
> so I can't do the testing you speak of.
There is no need: I had tried this on -STABLE with environment
variable MALLOC_OPTIONS set to 'J' -- it dumps core. The problem
seems to be in the git-fetch:
-
$ MALLOC_OPTIONS=JA git-fetch --update-head-ok
Segmentation fault: 11 (core dumped)
-
This happens inside git repository of xserver and 100% reproducible
for my both -CURRENT and -STABLE.
> I would want to see if maybe our gcc on
> - -current might have been made with a default of emitting no stack frames,
> which
> I would guess might have this effect.
The stack seems to be smashed at the second call to
'transport_unlock_pack': the argument called 'transport' seems to
carry the pointer to the area, filled by malloc() with byte 0x5a:
-
$ MALLOC_OPTIONS=JA gdb git-fetch
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) run --update-head-ok
Starting program: /usr/local/bin/git-fetch --update-head-ok
Program received signal SIGSEGV, Segmentation fault.
0x4841de8b in free () from /lib/libc.so.7
(gdb) bt
#0 0x4841de8b in free () from /lib/libc.so.7
#1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
at transport.c:811
#2 0x08066927 in unlock_pack () at builtin-fetch.c:56
#3 0x48468fe3 in __cxa_finalize () from /lib/libc.so.7
#4 0x4842199a in exit () from /lib/libc.so.7
#5 0x0804b15b in handle_internal_command (argc=2, argv=0x)
at git.c:379
#6 0x0804b8be in main (argc=2, argv=Error accessing memory address 0x10: Bad
address.
) at git.c:414
(gdb) fr 1
#1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
at transport.c:811
811 free(transport->pack_lockfile);
(gdb) print *transport
$1 = {remote = 0x5a5a5a5a,
url = 0x5a5a5a5a ,
data = 0x5a5a5a5a, remote_refs = 0x5a5a5a5a, set_option = 0x5a5a5a5a,
get_refs_list = 0x5a5a5a5a, fetch = 0x5a5a5a5a, push = 0x5a5a5a5a,
disconnect = 0x5a5a5a5a,
pack_lockfile = 0x5a5a5a5a ,
verbose = -2}
(gdb)
-
I don't believe that __cxa_finalize should call unlock_pack, so
stack seems to be smashed somewhere before.
> I guess I could test this, and if it's so, recompile all my libraries to undo
> that, because I abhor doing things that utterly block any troubleshooting at a
> minimal savings elsewhere.
You don't need to recompile anything to enable malloc debugging.
The easiest way is to set MALLOC_OPTIONS to the needed malloc
flags.
--
Eygene
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
Chuck, good day. Tue, Jun 03, 2008 at 04:41:40PM -0400, Chuck Robey wrote: > I am having problems with the git out of ports git-fetch keeps on dumping > core when I try update of xorg (the initial checkout works ok). I'm running > FreeBSD-current ... does anyone have any idea why this might be? What version of Git you're using and what protocol is used for updating, native git or http? Any possibility of using ElectricFence (devel/ElectricFence) for chasing memory-related troubles? -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Yarrow's Counter
Good day. Sun, Apr 20, 2008 at 06:31:35PM +0100, RW wrote: > > this modification seems not to help anything, > > It possibly doesn't help with an attack against Yarrow itself, but it > means that 512 bits of entropy, rather than 256 bits, can be read-out > from /dev/random. The only source of entropy is the entropy pool. The key and the counter are both derived from this pool, so if you will concatenate two 256 bit values you will not gain more entropy. Consider the following case: you have only two input values that are fed to you by the pool. And then you're doing whatever you want to generate the key and the counter: hash something, encrypt something, etc. The resulting entropy will be not more than one (if there are no additional sources of randomness and the algorithm is known): you just should test two input values to get the possible key and counter spaces. Am I missing something? -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Yarrow's Counter
Good day. Sat, Apr 19, 2008 at 05:56:55PM +0100, RW wrote: > The random number generator in FreeBSD's Yarrow implementation uses > AES256 in counter mode. When a reseed occurs the generator is > reinitialised like this: > > - generate a new cypher-key from the pool[s] and the old key > - zero the counter > - encrypt the (zeroed) counter with the new key The latter two are better explained as "generate new counter as the result of encryption of a number 'zero' with the new key". > My question is: why zero the counter? It is per paper about Yarrow design: see http://www.schneier.com/paper-yarrow.html page 11, section 5.3, step 4. > If it's not zeroed then the old counter is encrypted instead, and after > a few reseeds the counter will accumulate an independent 256 bits of > entropy, rather than being a function of the new key. As the seventh paragraph of section 5.3 says, "There is no security reason why we would set a new value for the counter C". And deriving the new value of C from the old one will not add any additional entropy -- you're producing the old C and new key from the same "entropy source", so this won't give you more entropy: you have two dependent values. Moreover, as the last paragraph of page 9 says "...the counter value C is assumed to be known to the attacker", Yarrow was designed with this motto in mind. As I see it, the key reasoning is that for the perfect encryption function in the counter mode, there is no reason to keep the counter to be secret: it is just nonce, nothing more. Only the key should be kept safe. > Should I submit a patch, it's simply a matter of deleting two > lines in reseed() in sys/dev/random/yarrow.c. > > >yarrow_hash_finish(&context, temp); >yarrow_encrypt_init(&random_state.key, temp); > >/* 4. Recompute the counter */ > >for (i = 0; i < 4; i++) <--- >random_state.counter[i] = 0; <--- > >yarrow_encrypt(&random_state.key, random_state.counter, temp); >memcpy(random_state.counter, temp, sizeof(random_state.counter)); I would not do it without consultations with Yarrow's creators: this modification seems not to help anything, but can break something. But your mileage may vary, as usual ;)) -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feature request
Patrick, good day. Mon, Mar 31, 2008 at 11:18:56AM -0700, Patrick Dung wrote: > 4. LVM and file systems > > As of FreeBSD 7.0, ZFS is ported. > This is great as FreeBSD do not have LVM in the past. FreeBSD has gvinum since approximately 5.x and vinum since rather old days (3.0). Is something wrong with these LVMs? -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: synchronous freebsd print
Sanjeev, Wed, Feb 27, 2008 at 03:00:46AM -0800, Sanjeev Kumar.S wrote: > and Yes in the kernel code I have a "\n" at the end > of my print, still the print is not complete and > the line next to it that causes the crash does > not give the result I want. Is this a common > scenario or am I doing something wrong. If you're not defining PRINTF_BUFR_SIZE, then, judging by the /sys/kern/subr_prf.c, output will be unbuffered in any case. However, kernel printf is not protected by locks, so it can be interrupted by another thread, if I am correct. May be ddb(4) will become your friend? -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Zeroing sensitive memory chunks [Was: Security Flaw in Popular Disk Encryption Technologies]
Gregory, good day. Tue, Feb 26, 2008 at 07:42:17PM +0100, [EMAIL PROTECTED] wrote: > Quoting Eygene Ryabinkin <[EMAIL PROTECTED]>: > > > *) New function OPENSSL_cleanse(), which is used to cleanse a section of > >memory from it's contents. This is done with a counter that will > >place alternating values in each byte. This can be used to solve > >two issues: 1) the removal of calls to memset() by highly optimizing > >compilers, and 2) cleansing with other values than 0, since those can > >be read through on certain media, for example a swap space on disk. > >[Geoff Thorpe] > > > > The '1)' is what I was talking about. '2)' is not very clear to > > me now, I should research what Geoff meant. If anyone has an idea, > > please comment. > > I thought it might mean that on certain media, such as disks, data > can be read even after it has been overwriten a certain number of > times (magnetic properties of the media, this is a method used by > some police labs to recover lost data, I've been told, but maybe > the man was just a paranoid). So even "cleansing" a crypted swap > space this way would not render it safe (you would have to repeat > it enough times so that the layers are definitively overwritten) Yes, Geoff just responded to my private question: it was Peter Gutmann, who pointed him to the thing you're talking about. There is a paper by Peter, http://www.usenix.org/publications/library/proceedings/sec96/full_papers/gutmann/ I still don't understand how cleaning of a memory area will help to clean the swapped page, but may be there are some systems which will update the swapped page on the memory access. May be this even called 'read-through' -- I really don't know. Perhaps this will help for the memory-mapped files, but may be not: the system's write cache can collapse many successive overwrites to just one. The mmap'ped files are using the write cache, aren't they? Thanks for the comment! -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Zeroing sensitive memory chunks [Was: Security Flaw in Popular Disk Encryption Technologies]
Good day.
I am posting the follow-up to the -hackers and CC'ing to the
-security, because some more-or-less nasty points were found.
Sat, Feb 23, 2008 at 10:32:02PM +0300, Eygene Ryabinkin wrote:
> But there is another concern with bzero(): it is well-known function.
> Especially for compilers. And it is bad: some arrays inside g_eli,
> that hold decryption keys are the local variables. And they are
> not used after the final bzero() call, so optimizing compiler can
> eliminate the bzero() completely, as the "not relevant". I don't
> know if GCC does it -- I should check and will do this tomorrow,
> because it is already too late in Russia for this day ;))
Generally speaking, there is nothing special in this finding: "Secure
Programming Cookbook for C and C++" from O'Reilly warns the reader
about it (page 705 and below, citing by the current edition,
http://www.oreilly.com/catalog/secureprgckbk/).
OK, gcc 4.2.1 does the dead code removal and sometimes bzero/memset
can be omitted (gcc 3.4.6, the one I have at hand from the 3.x
branch, is never omitting these functions). It really depends on
the size of the local array.
The test program is:
-
#include
#include
#include
#define bar(n) \
void bar ## n(void) \
{ \
char b[n]; \
scanf("%" #n "s", b); \
memset(b, '\0', sizeof(b)); \
}
#define foo(n) \
void foo ## n(void) \
{ \
char b[n]; \
scanf("%" #n "s", b); \
bzero(b, sizeof(b));\
}
foo(16)
foo(24)
foo(32)
foo(1024)
bar(16)
bar(24)
bar(28)
bar(30)
bar(31)
bar(32)
bar(1024)
int main(void)
{
foo16();
foo24();
foo28();
foo32();
foo1024();
bar16();
bar24();
bar28();
bar30();
bar31();
bar32();
bar1024();
return 0;
}
-
Compiled with '-O' switch, it eliminates bzero/memset for all functions
with the local array size < 32. For example, this is the assembler code
of bar31 (taken from 'gcc -O -S -o test.s test.c'):
-
.globl bar31
.type bar31, @function
bar31:
pushl %ebp
movl%esp, %ebp
subl$40, %esp
leal-31(%ebp), %eax
movl%eax, 4(%esp)
movl$.LC2, (%esp)
callscanf
leave
ret
.size bar31, .-bar31
.section.rodata.str1.1
.LC3:
.string "%30s"
.text
.p2align 4,,15
-
The simple PoC session transcript follows:
-
$ cat poc.c
#include
#include
#include
void pass(void)
{
char buffer[31];
printf("Password: ");
scanf("%30s", buffer);
memset(buffer, 0, sizeof(buffer));
}
int main(void)
{
pass();
return 0;
}
$ gcc -O -g -o poc poc.c
$ gdb poc
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) b main
Breakpoint 1 at 0x8048450: file poc.c, line 15.
(gdb) run
Starting program: /some/path/poc
Breakpoint 1, main () at poc.c:15
15 {
(gdb) step
main () at poc.c:16
16 pass();
(gdb) step
pass () at poc.c:9
9 printf("Password: ");
(gdb) print &buffer
$1 = (char (*)[31]) 0xbfbfec69
(gdb) step
10 scanf("%30s", buffer);
(gdb)
Password: ASDFGHJKLQWERTYUIO
12 }
(gdb)
main () at poc.c:18
18 }
(gdb)
0x080483af in _start ()
(gdb) x/35c 0xbfbfec69
0xbfbfec69: 65 'A' 83 'S' 68 'D' 70 'F' 71 'G' 72 'H' 74 'J' 75 'K'
0xbfbfec71: 76 'L' 81 'Q' 87 'W' 69 'E' 82 'R' 84 'T' 89 'Y' 85 'U'
0xbfbfec79: 73 'I' 79 'O' 0 '\0' 1 '\001'0 '\0' 0 '\0' 0 '\0'
-36 'э'
0xbfbfec81: -20 'Л' -65 '©' -65 '©' 0 '\0' 0 '\0' 0 '\0' 0 '\0' -104
'\230'
0xbfbfec89: -20 'Л' -65 '©' -65 '©'
(gdb)
-
Currently, I was not able to identify gcc's code that removes the
memset in question, so if anyone has ideas -- it will be appreciated.
Zeroing sensitive memory chunks [Was: Security Flaw in Popular Disk Encryption Technologies]
Jeremy, list, good day. Sat, Feb 23, 2008 at 10:56:20AM -0800, Jeremy Chadwick wrote: > > A possible counter-measure would be to add wiping features to the RAM > > modules themselves. When power is lost, the memory could wipe itself. Still > > not perfect, but would certainly help. > > Proper software should be memset() or bzero()'ing memory space it > mallocs. I've gotten in the habit of doing this for years, purely as a > safety net. If said software doesn't do this, it's very likely > succeptable. > > So the OP's question about ELI/GELI stands -- does it properly zero out > memory it allocates before using it? Excuse me, but I think that you're confusing two things: zeroing or, generally, initializing memory before the first use (it what is you're talking about) and sanitizing sensitive data like passwords and keys after they were used (it is what OP was talking about). The answer to the original question: yes, geli module cleans all keys and passphrases after use with bzero(). As it was mentioned, this will not help you, if you have your geli-encrypted partition mounted and someone performs the attack by replugging the power and dumping the memory image. But there is another concern with bzero(): it is well-known function. Especially for compilers. And it is bad: some arrays inside g_eli, that hold decryption keys are the local variables. And they are not used after the final bzero() call, so optimizing compiler can eliminate the bzero() completely, as the "not relevant". I don't know if GCC does it -- I should check and will do this tomorrow, because it is already too late in Russia for this day ;)) For example, OpenSSL has the OPENSSL_cleanse() function whose purpose is two-fold (from http://cvs.openssl.org/chngview?cn=9301): - *) New function OPENSSL_cleanse(), which is used to cleanse a section of memory from it's contents. This is done with a counter that will place alternating values in each byte. This can be used to solve two issues: 1) the removal of calls to memset() by highly optimizing compilers, and 2) cleansing with other values than 0, since those can be read through on certain media, for example a swap space on disk. [Geoff Thorpe] - The '1)' is what I was talking about. '2)' is not very clear to me now, I should research what Geoff meant. If anyone has an idea, please comment. May be the crypto(4,9) framework should receive the function, that will be simular to the OPENSSL_cleanse. And that function should be used for wiping of the sensitive data. Will try to post an update once it will be more clear to me. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics
Cristian, good day. Thu, Feb 21, 2008 at 01:57:08AM +0200, Cristian KLEIN wrote: >> Yes, please, try the mentioned patch and report back ;)) > > Sorry for the really long delay. No problems ;)) > The patch works perfectly on my Fujitsu-Siemens V5545. Thanks for the report! Norikatsu already kindly committed my patch, so you can update your ports and rebuild Synaptics driver -- it should work too and you'll not miss the modifications. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics Xorg driver for FreeBSD/amd64
Norikatsu, good day. Wed, Feb 20, 2008 at 02:34:17AM +0900, Norikatsu Shigemura wrote: > > Xorg server 1.4 already has "AllowEmptyInput", so Giulio and others > > who want to run only Synaptics driver, can add the string > > - > > Option "AllowEmptyInput" > > - > > to their "ServerFlags" section and see no automagically added devices. > > I've got it! I confidently committed these solutions! Thank you for the commit! I can only add that the "AllowEmptyInput" appeared in the xorg-server-1.3.99.0, dated 31-Jul-2007 (see http://xorg.freedesktop.org/releases/individual/xserver/). And FreeBSD port of xorg-server was updated from 1.2 to 1.4 at Thu Sep 13 19:44:55 2007: http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-servers/xorg-server/distinfo.diff?r1=1.7;r2=1.8 So maybe it is worth to mention in the pkg-message about old hack with the 'void' input device -- just in case someone will try to run new Synaptics driver with older xorg-server and problems will arise. > Thank you!! My pleasure! ;)) -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics Xorg driver for FreeBSD/amd64
Giulio, Mon, Feb 18, 2008 at 10:54:35PM +0100, Giulio Ferro wrote: > Eygene Ryabinkin wrote: >> Please, uncomment your 'Mouse1' device inside "ServerLayout", start >> moused and try again. The '' should disappear. >> And probably mices will start working. > > Ok, now I've uncommented both mouse1 and synaptics: > > InputDevice "Mouse1" "CorePointer" > InputDevice "Keyboard1" "CoreKeyboard" > InputDevice "Synaptics_Touchpad""CorePointer" > > > and the moused demon. > > Here's is what I get: > 1) The mouse pointer now moves Cool. > 2) The drag and drop with double click on the touchpad _doesn't_ work Never tried this feature myself. Will try it tomorrow on my notebook. Did it ever worked for you? > 3) Window scrolling with the touchpad _doesn't_ work (either horizontally or > vertically) Is something reported if you spawn 'xev' and try to scroll via touchpad while the pointer is upon the xev window? > I attach the log of the attempt. Seems like this is the old one: > (==) Log file: "/var/log/Xorg.0.log", Time: Mon Feb 18 15:46:59 2008 > [...] > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/psm0" > (--) : Device: "/dev/psm0" > (==) : Protocol: "Auto" > (**) Option "AlwaysCore" > (**) : doesn't report core events > (==) : Emulate3Buttons, Emulate3Timeout: 50 > (**) : ZAxisMapping: buttons 4 and 5 > (**) : Buttons: 9 > (**) : Sensitivity: 1 > (II) evaluating device () > (II) XINPUT: Adding extended input device "" (type: MOUSE) > (II) evaluating device (Synaptics_Touchpad) > (II) XINPUT: Adding extended input device "Synaptics_Touchpad" (type: MOUSE) > (II) evaluating device (Keyboard1) > (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) > Synaptics DeviceInit called > SynapticsCtrl called. > (II) : SetupAuto: hw.iftype is 3, hw.model is 13 > (II) : SetupAuto: protocol is SysMouse > (WW) fcntl(9, O_ASYNC): Inappropriate ioctl for device > Synaptics DeviceOn called > (EE) xf86OpenSerial: Cannot open device /dev/psm0 > Device busy. > (WW) Synaptics_Touchpad: cannot open input device > couldn't enable device 3 > > Fatal server error: > Caught signal 10. Server aborting > > Synaptics DeviceOff called -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics Xorg driver for FreeBSD/amd64
Giulio, Roman, Mon, Feb 18, 2008 at 07:04:13PM +0300, Eygene Ryabinkin wrote: > Aargh, this is the funny thing: you have no devices that are handled > by the 'mouse' driver. And Xorg automatically adds one. > > Please, uncomment your 'Mouse1' device inside "ServerLayout", start > moused and try again. The '' should disappear. > And probably mices will start working. There is a better way that I had found while was answering to Norikatsu's letter: add the string - Option "AllowEmptyInput" - to your xorg.conf "ServerFlags" section and you should see no additional mouse devices and probably Synaptics mice will be alive. Roman, this concerns you too ;)) Please, try it if you prefer to use single pointer from touchpad. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics Xorg driver for FreeBSD/amd64
Norikatsu, good day. Tue, Feb 19, 2008 at 02:35:24AM +0900, Norikatsu Shigemura wrote: > Hi Eygene, thanks for your summary! You're welcome! > On Mon, 18 Feb 2008 19:04:13 +0300 > Eygene Ryabinkin <[EMAIL PROTECTED]> wrote: > > >> It seems to me that you have another mouse device called ' > >> pointer>' that uses "auto" protocol and finds your mouse at /dev/psm0 > > >> and being SysMouse. Can you show your full xorg.conf? > > > Sure, find it attached... > > Aargh, this is the funny thing: you have no devices that are handled > > by the 'mouse' driver. And Xorg automatically adds one. > > Please, uncomment your 'Mouse1' device inside "ServerLayout", start > > moused and try again. The '' should disappear. > > And probably mices will start working. > > It will be good to see Xorg.log from this attempt. > > I'm using x11-drivers/synaptics on FreeBSD/i386. I don't have > any problem which many people said. > > I have two questions: > > a. Anyone, do you install x11-drivers/xf86-input-void? > I didn't install x11-drivers/xf86-input-void. Personally, I am not using xf86-input-void, because I am using standard system mouse with synaptics touchpad, so I don't need 'void' input device. > b. If you install x11-drivers/xf86-input-void, please check > following setting. > > Section "InputDevice" > Identifier "dummy" > Driver "void" > EndSection > > I read source files of Xserver and void driver, but I didn't > understand these relations:-(. If you'll look at http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;h=dbe158efc6e365cd5bd064d848df3a4f0c0d35f4;hb=43d9edd31e31b33b9da4a50d8ab05004881c8d5a;f=hw/xfree86/common/xf86Config.c#l1611 you will see that server tries to add the mouse driver if there is no drivers of type 'mouse' or 'void'. The hack with adding the "dummy" input device with type "void" disables generation of default mouse driver. This was the true hack and it was a bit beautified in http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=ba9f5138fc32a7a7b97bcf941bc92751b7c6c2c0 now there is a boolean option "AllowEmptyInput" that inhibits creation of core mouse and keyboard in any case. > So I don't know that it's > correct to fix this problem by way of b. And, if x11-drivers/ > xf86-input-void is not installed, that's solution will be crashed. Xorg server 1.4 already has "AllowEmptyInput", so Giulio and others who want to run only Synaptics driver, can add the string - Option "AllowEmptyInput" - to their "ServerFlags" section and see no automagically added devices. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics Xorg driver for FreeBSD/amd64
Mon, Feb 18, 2008 at 04:49:13PM +0100, Giulio Ferro wrote: > Eygene Ryabinkin wrote: >> Yes, the following lines are very suspicious: >> - >> - >> >> It seems to me that you have another mouse device called '> pointer>' that uses "auto" protocol and finds your mouse at /dev/psm0 >> and being SysMouse. Can you show your full xorg.conf? >> > > > Sure, find it attached... Aargh, this is the funny thing: you have no devices that are handled by the 'mouse' driver. And Xorg automatically adds one. Please, uncomment your 'Mouse1' device inside "ServerLayout", start moused and try again. The '' should disappear. And probably mices will start working. It will be good to see Xorg.log from this attempt. Thank you! -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics Xorg driver for FreeBSD/amd64
Giulio, Mon, Feb 18, 2008 at 04:00:43PM +0100, Giulio Ferro wrote: > Eygene Ryabinkin wrote: >> And if you'll try >> 'InputDevice "Synaptics_Touchpad" "CorePointer" "SendCoreEvents"'? >> >> > Nothing changes, sorry... > >> If not, drop me a letter, I'll try to get the real hardware into >> my hands and test it. But this likely won't be done until the end >> of the week, sorry. >> > > Thanks again. I include the complete log of the xorg session, I hope it can > help you somehow. Yes, the following lines are very suspicious: - > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/psm0" > (--) : Device: "/dev/psm0" > (==) : Protocol: "Auto" > (**) Option "AlwaysCore" > (**) : doesn't report core events > (==) : Emulate3Buttons, Emulate3Timeout: 50 > (**) : ZAxisMapping: buttons 4 and 5 > (**) : Buttons: 9 > (**) : Sensitivity: 1 > (II) evaluating device () > (II) XINPUT: Adding extended input device "" (type: MOUSE) > (II) evaluating device (Synaptics_Touchpad) > (II) XINPUT: Adding extended input device "Synaptics_Touchpad" (type: MOUSE) > (II) evaluating device (Keyboard1) > (II) XINPUT: Adding extended input device "Keyboard1" (type: KEYBOARD) > Synaptics DeviceInit called > SynapticsCtrl called. > (II) : SetupAuto: hw.iftype is 3, hw.model is 13 > (II) : SetupAuto: protocol is SysMouse > (WW) fcntl(9, O_ASYNC): Inappropriate ioctl for device > Synaptics DeviceOn called > (EE) xf86OpenSerial: Cannot open device /dev/psm0 > Device busy. > (WW) Synaptics_Touchpad: cannot open input device > couldn't enable device 3 - It seems to me that you have another mouse device called '' that uses "auto" protocol and finds your mouse at /dev/psm0 and being SysMouse. Can you show your full xorg.conf? Thanks! -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics Xorg driver for FreeBSD/amd64
Mon, Feb 18, 2008 at 02:49:00PM +0100, Giulio Ferro wrote: > Eygene Ryabinkin wrote: >> Please, try again if you have some spare time. > > Ok. Now the server starts, Good ;)) > but the mouse pointer isn't moving... Bad :(( > in the ServerLayout section I have this: >#InputDevice "Mouse1" "CorePointer" >InputDevice "Keyboard1" "CoreKeyboard" > InputDevice "Synaptics_Touchpad""CorePointer" And if you'll try 'InputDevice "Synaptics_Touchpad" "CorePointer" "SendCoreEvents"'? I have it in my Synaptics config @i386 and I vaguely recall that this was needed to enable the touchpad and USB mouse to work together. May be this will fix your problems. If not, drop me a letter, I'll try to get the real hardware into my hands and test it. But this likely won't be done until the end of the week, sorry. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics Xorg driver for FreeBSD/amd64
Giulio, Mon, Feb 18, 2008 at 01:39:50PM +0100, Giulio Ferro wrote: > first of all thanks for your effort. No problems ;)) > Unfortunately I couldn't still get the synaptyc driver work on my laptop. > > Here's what I did: > 1) I extracted the port driver with "make extract patch" > 2) put your patch in /usr/ports/x11-drivers/synaptics/files (I named it > "newpatch") > 3) applied the patch with that directory with patch < newpatch No, the patch I had supplied is the patch-to-the-patch ;)) So you should 1) Do 'make clean' in the port's directory. 2) Apply the patch with 'patch -p1 < /path/to/the/supplied/patchfile'. 3) Build and install the port. Sorry, I was not clear enough on how to apply the modification. Please, try again if you have some spare time. Thanks! -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics
Cristian, good day. Fri, Feb 08, 2008 at 10:32:51PM +0200, Cristian KLEIN wrote: > Thank you very much for 'pinging'. :) As the driver synaptics driver din > not change for month, I speculate there might have been a change in the > Xorg API, especially related to sucking configuration options. No, I had found the first problem and sent the message to the list shortly after the 'ping' mail. It has the patch attached. If you had not received it, it is strange, but anyway, here is the URL http://lists.freebsd.org/pipermail/freebsd-hackers/2008-February/023272.html Make mistakenly thought that your Synaptics driver should be compiled for i386, not for amd64. Patch will change the situation back to normal. > Is there any way I could help? Yes, please, try the mentioned patch and report back ;)) -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nvi strangeness
Fri, Feb 08, 2008 at 02:20:09PM +0300, Eygene Ryabinkin wrote: > > None of this is documented anywhere. > > $ zcat /usr/share/doc/usd/13.viref/paper.ascii.gz | less > and search for the 'percent sign'. Hmm, it is much better to search for 'Ex Addressing' ;)) -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nvi strangeness
Dag-Erling, good day. Speaking for the system's nvi (not the ports one -- not using it). Fri, Feb 08, 2008 at 11:28:42AM +0100, Dag-Erling Sm??rgrav wrote: > As everybody knows, the ex/vi command for regexp substitution is > >[range] s[ubstitute] [/pattern/replace/] [options] [count] [flags] > > The man page does not document the syntax for ranges (nor for offsets or > counts for that matter) > > Assuming the syntax is the same as for ed / sed, the following should > replace every occurrence of the word wait with the word delta: > > :,s/\/delta/g > > where "," means "the entire file" Nope, "," means "from the current line to the current line". So :,s/anything/the other thing/g is equal to plain :s/anything/the other thing/g > That doesn't work, however, and neither does "1,"; only "X,Y" works, so > if you want to substitute in the entire file, you first have to find out > how long it is, then manually type in that number. > > ...or you could use the following (courtesy of roberto@): > > :%s/\/delta/g :1,$s/anything/the other thing/ will be the same as the ':%s...'. But ':%s...' is shorter to type ;)) Moreover, "1," will select lines from the first one to the current one. And, for example, ",+3" will select four lines, counting from the current and going down; "-2," will select three lines, counting from the current and going up. > None of this is documented anywhere. $ zcat /usr/share/doc/usd/13.viref/paper.ascii.gz | less and search for the 'percent sign'. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics
Me again. Mon, Feb 04, 2008 at 05:41:18PM +0300, Eygene Ryabinkin wrote: > This is a sort of 'ping' mail, sorry. To the point: I had reproduced > the problem and will start looking into it once this message will > fly from my mailserver. Stay tuned ;)) OK, things should be better with the attached patch. I was not able to fully test the resulting Synaptics driver, since I have no Synaptics beast at my amd64 machine ;)) But with the provided patch, my Synaptics driver tries to search for the psm device, as I told him, so, please, give it a try. Must be patched with 'patch -p1' and one should be in the port directory. -- Eygene >From 083c1be4c91da739436f2b1e509a96512ac05867 Mon Sep 17 00:00:00 2001 From: Eygene Ryabinkin <[EMAIL PROTECTED]> Date: Mon, 4 Feb 2008 19:17:43 +0300 Subject: [PATCH] Fix compilation at amd64 by overriding the ARCH variable properly. FreeBSD make sets ARCH variable to 'amd64' [1] and invokes GNU make. It inherits the ARCH variable and refuses to set it via ordinary '=' operator. So we must force ARCH assignments. [1] Try 'make -V ARCH' in the port directory. Signed-off-by: Eygene Ryabinkin <[EMAIL PROTECTED]> --- files/patch-Makefile |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/files/patch-Makefile b/files/patch-Makefile index 1ae3cbe..90870c5 100644 --- a/files/patch-Makefile +++ b/files/patch-Makefile @@ -1,5 +1,5 @@ Makefile.orig Sun Jul 16 00:58:26 2006 -+++ Makefile Sun Aug 13 10:47:35 2006 +--- Makefile.orig 2006-07-15 19:58:26.0 +0400 Makefile 2008-02-04 19:11:33.0 +0300 @@ -12,14 +12,14 @@ MANDIR = $(DESTDIR)$(PREFIX)/man @@ -8,7 +8,8 @@ + ARCH = $(shell uname -m) endif ifeq ($(ARCH),amd64) - ARCH = x86_64 +- ARCH = x86_64 ++ override ARCH = x86_64 endif ifeq ($(ARCH),x86_64) ARCH_DEFINES = -D__x86_64__ -D_XSERVER64 -- 1.5.3.8 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics
Cristian, good day. Wed, Jan 23, 2008 at 01:26:41PM +0200, [EMAIL PROTECTED] wrote: > >> I just ran into the same problem. In xorg.conf I explicitly told the > >> synaptics driver to use "psm" and "/dev/psm0", but the error message > >> would > >> suggest that it uses "event". > >> > >> Also, I tried to change the source code of the synaptics driver > >> (synaptics.c) and hard-coded "psm" as the only driver, no matter what > >> xorg.conf says. Synaptics still would not start, but this time > >> complaining > >> that no device was specified. Please note that I had "Device" in my > >> xorg.conf, but the error suggests that the driver ignored it. > > Suppose I use the attached xorg.conf file, at some point, > /var/log/Xorg.0.log shows the following error: > > (II) Synaptics touchpad driver version 0.14.6 (1406) > Synaptics_Touchpad no synaptics event device found (checked 10 nodes) > Synaptics_Touchpad The /dev/input/event* device nodes seem to be missing > (EE) xf86OpenSerial: No Device specified. > Synaptics driver unable to open device > (EE) PreInit failed for input device "Synaptics_Touchpad" > (II) UnloadModule: "synaptics" > > As you said, it looks like synaptics is trying to use the "auto" protocol, > although the configuration file tells it to use "psm". > > Now, if I put the attached patch in x11-drivers/synaptics/files, using the > same xorg.conf, synaptics will fail like this: > > (II) Synaptics touchpad driver version 0.14.6 (1406) > (EE) xf86OpenSerial: No Device specified. > Synaptics driver unable to open device > (EE) PreInit failed for input device "Synaptics_Touchpad" > (II) UnloadModule: "synaptics" > > It almost looks as if I have to hardcode the device too, because synaptics > certainly ignores my options. This is a sort of 'ping' mail, sorry. To the point: I had reproduced the problem and will start looking into it once this message will fly from my mailserver. Stay tuned ;)) -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: double start of scripts in /usr/local/etc/rc.d
Mon, Feb 04, 2008 at 11:56:21AM +0300, sam wrote: >> Then remove /usr/X11R6/etc from the local_startup variable >> (in /etc/rc.conf and/or in /etc/defaults/rc.conf) and enjoy single >> startup of scripts ;)) > > thx > iam deleted this symlink No, no, no: you should not remove the symlink itself. By the immortal words of Kris Kennaway in /usr/ports/UPDATING: - When the merge operation completes successfully, the /usr/X11R6 directory hierarchy will be removed and replaced by a symlink to /usr/local. This symlink is necessary because some binary ports (and some remaining source ports) have hard-coded references to /usr/X11R6. - So you can hit the problem of hard-coded references. Just remove the string /usr/X11R6/etc from startup configuration as was described above. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: double start of scripts in /usr/local/etc/rc.d
Fri, Feb 01, 2008 at 04:04:51PM +0300, sam wrote: > Eygene Ryabinkin wrote: >> Fri, Feb 01, 2008 at 11:59:44AM +, Tom Evans wrote: >> >>> Sam: what is the output of grep local_startup /etc/rc.conf >>> /etc/defaults/rc.conf >>> >> >> And is your /usr/X11R6 symlinked to /usr/local? >> > have this symlink Then remove /usr/X11R6/etc from the local_startup variable (in /etc/rc.conf and/or in /etc/defaults/rc.conf) and enjoy single startup of scripts ;)) Seems like you had updated your system to Xorg 7.2, but forgot to run /usr/ports/Tools/scripts/mergebase.sh or mergebase.sh failed to remove /usr/X11R6/etc from local_startup. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: double start of scripts in /usr/local/etc/rc.d
Fri, Feb 01, 2008 at 11:59:44AM +, Tom Evans wrote: > Sam: what is the output of > grep local_startup /etc/rc.conf /etc/defaults/rc.conf And is your /usr/X11R6 symlinked to /usr/local? -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics
Cristian, good day. Mon, Jan 21, 2008 at 11:06:26PM +0200, Cristian KLEIN wrote: > Eygene Ryabinkin wrote: >> But what protocol is selected? From your Xorg log I assume that >> it is either "event", "auto-dev" or not set at all. > > I just ran into the same problem. In xorg.conf I explicitly told the > synaptics driver to use "psm" and "/dev/psm0", but the error message would > suggest that it uses "event". > > Also, I tried to change the source code of the synaptics driver > (synaptics.c) and hard-coded "psm" as the only driver, no matter what > xorg.conf says. Synaptics still would not start, but this time complaining > that no device was specified. Please note that I had "Device" in my > xorg.conf, but the error suggests that the driver ignored it. Could you please provide your Xorg configuration file and the Xorg logs for the run when you had hardcoded psm driver. It will also be good to see the modified Synaptics driver source file. And the version and platform for your FreeBSD is? > It almost seems that no matter what options I pass to synaptics, it does > not receive them. Is it possible that Xorg's option retrieval functions > have changed making the (relatively) old synaptics unusable? Maybe, but I am running Synaptics driver on my laptop for years and it works now without any problems. My laptop is i386, it runs FreeBSD 7-PRERELEASE, Xorg server 1.4_3,1 and synaptics 0.14.6_2. If you'll provide the information, I will try to look at the problem, but I expect to start investigations next week. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
