Re: RCS file ownership?

[athompso]

Thank you for that detail!
Addressing this one corner case would require substantial changes, I
think.  Not worth it, in my opinion.
I think it would be worthwhile describing the multi-user mode of
operation of RCS in the manual, as it's currently completely
absent/omitted. Patch coming soon, maybe tomorrow if I can make time.
-Adam
On Apr. 29, 2020 21:28, Theo de Raadt  wrote:

  athom...@athompso.net wrote:

  > Heh, good point.  Didn't even occur to me because as it happens, I
  am
  > running as root and would like to not change the ownership.-Adam
  > On Apr. 29, 2020 13:32, Anders Andersson 
  wrote:
  >
  >   On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson
  
  >   wrote:
  >   >
  >   > When I use co(1) with "-l" to check out a file (and/or "ci -l")
  is
  >   there
  >   > any way to preserve file ownership and *not* have it reset to
  the
  >   user
  >   > running co(1) or ci(1)?
  >   > I don't see anything in rcs(1), co(1) or ci(1) that even
  mentions
  >   the
  >   > fact that the file will wind up owned by the user running the
  >   command.
  >   > Ideas?  Pointers to documentation?
  >
  >   How could it possibly do anything else unless you always run co
  as
  >   root?

  Our rcs tools do:

  52628 co   RET   kbind 0
  52628 co   CALL  unlink(0x7f7ed1f3)
  52628 co   NAMI  "ls.c"
  52628 co   RET   unlink -1 errno 2 No such file or directory
  52628 co   CALL 
  open(0x7f7ed1f3,0x601,0100444)
  52628 co   NAMI  "ls.c"
  52628 co   RET   open 4
  52628 co   CALL  kbind(0x7f7ec908,24,0x847da2a816b5d817)

  Which appears to be this:

  else {
  (void)unlink(dst);

  if ((fd = open(dst, O_WRONLY|O_CREAT|O_TRUNC, mode)) == -1)
  err(1, "%s", dst);

  I don't know what older or gnu rcs do.  I guess whichever way this is
  done
  it must balance concerns between atomicity of concurrent reads
  performed
  by earlier processes, versus replacement of a potentially active
  file.

  If the latter is chosen, it would unlink(), perform the open more
  carefully, check that it is in the right place with fstat, but then
  it needs some work for ftruncate (to get rid of extra file contents
  at the end).  If the open() failed, it might try an unlink followed
  by
  open()?

  Other rcs implimentations need to be checked.  It is better if they
  work
  the same.

Re: RCS file ownership?

[athompso]

Heh, good point.  Didn't even occur to me because as it happens, I am
running as root and would like to not change the ownership.-Adam
On Apr. 29, 2020 13:32, Anders Andersson  wrote:

  On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson 
  wrote:
  >
  > When I use co(1) with "-l" to check out a file (and/or "ci -l") is
  there
  > any way to preserve file ownership and *not* have it reset to the
  user
  > running co(1) or ci(1)?
  > I don't see anything in rcs(1), co(1) or ci(1) that even mentions
  the
  > fact that the file will wind up owned by the user running the
  command.
  > Ideas?  Pointers to documentation?

  How could it possibly do anything else unless you always run co as
  root?

Re: BGP changes to support CARP better

[athompso]

No, I'm seeing the same thing - the carp master advertises the carp IP as 
next-hop no matter what.
The carp backup advertises whatever you've told it to advertise via "set 
nexthop".
-Adam

On Dec 2, 2013 6:43 PM, Chris Cappuccio  wrote:
>
> andy [a...@brandwatch.com] wrote: 
> > Hi, 
> > 
> > Could someone help me with this issue we have found where the OpenBGPd 
> > rule 'match to bgppeerip set nexthop bgpcarpip' doesn't work if OpenBGPd is 
> > started whilst the OpenBSD host is a carp master. It only works if it is a 
> > CARP backup :( 
> > 
> > 
> > Or could someone give me a clue where in the source code to look so I can 
> > try to comment out the code which is checking the state of carp? This is 
> > desperately important for us for reasons discussed in this thread and 
> > others. 
> > 
> > Thanks for your time, Andy. 
> > 
> > PS; Thanks to Henning and Claudio for their great work with OpenBGPd. 
> > 
>
> Can you demonstrate the failure through any bgpd output or some other way? 
>
> For instance, does bgpd fail to advertise routes via bgp if it's the CARP 
> nexthop master? 
>
> Or does it all look like it should work, and just fail? 

Re: BGP changes to support CARP better

[athompso]

> PS; We are against 'sloppy state' so much because we cannot sanitize
> the sessions anywhere else (these firewalls connect to raw Transit).
>
> In the meantime I think we're going to be forced to use ifstated to
> shutdown OpenBGPd on the backup :(
>
> Ugly and very slow, but I would rather this than risk insecurity..
>
> Thanks for reading :)

I have (I think) almost exactly the same issue; doesn't pfsync between the
redundant BGP routers solve your state-tracking problem?

In my case, I have two BGP routers communicating with one upstream peer
(one session per router), *not* using the CARP IP to establish BGP
sessions.  I had started with one BGP session originating from the CARP
IP, but every time I failed over, all my announcements went away and
instead of a ~60sec outage I had a ~4hr partial outage while my routes
re-propagated and foreign ASes stopped damping the change.

At the moment, I've disabled pf altogether, but preliminary testing shows
that using pfsync solves my problem - both routers maintain the same state
table, so it no longer matters which router processes any given packet
(AFAICT).

-Adam Thompson
 athom...@athompso.net