Re: s6-log can create current with 640?

[Dewayne Geraghty]

Thank-you, Colin.

My brain turned to mush integrating logging with fifo queues across
multiple jails (aka very lightweight VMs) and disjoint users (userA
writes, userB reads).  Unfortunately they're across various jailed
systems, so the s6 fifo tools aren't applicable.  I appreciate your
advice, and yes, if there was anyone in the uucp group, I could be
labelled "overly permissive"!  ;^)

Kind regards, Dewayne.
PS I've gotten to like s6, it helped me discover a "workaround" for an
aslr issue with ntp, which under normal circumstance I would've given up.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241421

Re: s6-log can create current with 640?

[Colin Booth]

On Wed, Oct 23, 2019 at 01:27:24PM +1100, Dewayne Geraghty wrote:
> Is there any way to tell s6-log to set the mode to ./current to
> something other than 644?  640 is preferred?
> 
> For example: I write to the logdir /var/log/httpd/error which has privs:
> 
> /var/log/http
> drwx--  2 uucp  uucp   1.0K Oct 23 12:37 error/
> 
> Within /var/log/httpd/error
> -rwxr--r--  1 uucp  uucp   190K Oct 23 12:37 @40005dafaf1b180d862c.s*
> -rw-r-  1 uucp  uucp 0B Oct 23 12:37 state
> -rw-r--r--  1 uucp  uucp 0B Oct 23 12:37 current
> 
> I did try umask 037 but that just broke the pipe.
> 
> All my log files are of this form
> #!/usr/local/bin/execlineb -P
> s6-setuidgid uucp
> redirfd -r 0 /services/ntp/fifo
> /usr/local/bin/s6-log -b n28 r7000 s20 S700 !"/usr/bin/xz -7q"
> /var/log/ntpd
> 
> This is a big deal as I'm about to move my audit processing under s6-rc.
> 
> (Aside: Actually I write to a fifo and then redirfd for s6-log to pick
> up the content and manage the log files.  All works very nicely :) )

I know it isn't sexy but directory restrictions are good enough in this
situation. In your case, only the uucp user is allowed to descend into
that directory to start with so as long as that guarantee stays in place
the file permissions shouldn't matter. In fact, 640 is *more* permissive
than the parent directory due to the ability for accounts in the uucp
group to observe the file, even if they can't get to the directory to do
it. 

Cheers!
-- 
Colin Booth

s6-log can create current with 640?

[Dewayne Geraghty]

Is there any way to tell s6-log to set the mode to ./current to
something other than 644?  640 is preferred?

For example: I write to the logdir /var/log/httpd/error which has privs:

/var/log/http
drwx--  2 uucp  uucp   1.0K Oct 23 12:37 error/

Within /var/log/httpd/error
-rwxr--r--  1 uucp  uucp   190K Oct 23 12:37 @40005dafaf1b180d862c.s*
-rw-r-  1 uucp  uucp 0B Oct 23 12:37 state
-rw-r--r--  1 uucp  uucp 0B Oct 23 12:37 current

I did try umask 037 but that just broke the pipe.

All my log files are of this form
#!/usr/local/bin/execlineb -P
s6-setuidgid uucp
redirfd -r 0 /services/ntp/fifo
/usr/local/bin/s6-log -b n28 r7000 s20 S700 !"/usr/bin/xz -7q"
/var/log/ntpd

This is a big deal as I'm about to move my audit processing under s6-rc.

(Aside: Actually I write to a fifo and then redirfd for s6-log to pick
up the content and manage the log files.  All works very nicely :) )

Re: The "Unix Philosophy 2020" document

[Casper Ti. Vector]

On Tue, Oct 22, 2019 at 12:54:17PM -0400, Steve Litt wrote:
> What URL is the best one for us to publicize?

" for PDFs,
 for the source code"?
(I do not want to clutter the git repo with PDF files...)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: The "Unix Philosophy 2020" document

[Steve Litt]

On Tue, 22 Oct 2019 23:33:41 +0800
"Casper Ti. Vector"  wrote:

> On Sun, Oct 13, 2019 at 01:37:43AM +0800, Casper Ti. Vector wrote:
> > [...]  Consequently I think that, with an appropriate amount
> > of publicity for the document, much more people would be willing
> > to keep an eye on, migrate to, or even help develop daemontools-ish
> > systems, potentially creating a mini-avalanche effect or even
> > resulting in a turning point in the "init wars".  However, the
> > influx of people into our circle will also result in a lot of noise
> > (especially the noise from some ill-intentioned systemd proponents)
> > and a lot of additional technical workload, so I request Laurent
> > for a decision on whether to publicise the document; and provided
> > he agrees, I request you to help spread it to appropriate places.  
> 
> Through private mail with Laurent, I have confirmed that he agrees to
> the publicising (not just publication -- it has been on GitLab/GitHub
> for some time!) of this document.  So please help me spread the
> information to where it should be, and direct any interesting
> criticism to me if you find it necessary.  Thanks in advance.

What URL is the best one for us to publicize?




-- 
Steve Litt
Author: The Key to Everyday Excellence
http://www.troubleshooters.com/key
Twitter: http://www.twitter.com/stevelitt

Re: The "Unix Philosophy 2020" document

[Casper Ti. Vector]

On Sun, Oct 13, 2019 at 01:37:43AM +0800, Casper Ti. Vector wrote:
> [...]  Consequently I think that, with an appropriate amount
> of publicity for the document, much more people would be willing
> to keep an eye on, migrate to, or even help develop daemontools-ish
> systems, potentially creating a mini-avalanche effect or even resulting
> in a turning point in the "init wars".  However, the influx of people
> into our circle will also result in a lot of noise (especially the noise
> from some ill-intentioned systemd proponents) and a lot of additional
> technical workload, so I request Laurent for a decision on whether to
> publicise the document; and provided he agrees, I request you to help
> spread it to appropriate places.

Through private mail with Laurent, I have confirmed that he agrees to
the publicising (not just publication -- it has been on GitLab/GitHub
for some time!) of this document.  So please help me spread the
information to where it should be, and direct any interesting criticism
to me if you find it necessary.  Thanks in advance.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C