On Sat, Mar 06, 2021 at 09:56:34AM -0700, Theo de Raadt wrote:
> Matthieu Herrb <matth...@openbsd.org> wrote:
> 
> > On Fri, Mar 05, 2021 at 09:10:32PM +0300, Vadim Zhukov wrote:
> > > чт, 4 мар. 2021 г. в 02:02, Vadim Zhukov <persg...@gmail.com>:
> > > >
> > > > Hello all.
> > > >
> > > > Since xenodm has DEF_USER_AUTH_DIR set to "/tmp", we need to ignore
> > > > /tmp/.Xauth* in daily cleanup, don't we?
> > > >
> > > > Found the hard way a few minutes ago on my X240.
> > > 
> > > Thanks sthen@, I've realized this happens only when xenodm could not
> > > create ~/.Xauthority. In my case this happens because my laptop starts
> > > with /home mounted read-only, but there may be others. Mattieu, the
> > > xenodm logic itself is correct, right? If yes, anyone brave enough to
> > > okay the diff below then? :-)
> > 
> > Hi,
> > 
> > Yes I think the xenodm logic (inherithed from xdm) is correct.
> > 
> > Althoug in my experience, when an X session cnnot write to $HOME it
> > generally doesn't get very far (iirc not beeing able to write to
> > .xsession-errors used to be fatal)...

I tried to log in with a read-only /home and it failed as I remembered
it. Vadim are your doing something special in you X session to make
that work   ?

> > 
> > Anyways ok to skip that directory if it exists in daily.
> 
> It is not a directory -- it is a file.
> 
> I don't understand how this file is created.  Well-known names in /tmp
> are raceable -- therefore we and others increasingly use directories 
> containing
> files as a safer pattern.  Where is the code that creates this file?  Is it
> safe?  I am suspicious.

It's created by mkstemp(3) in
/usr/xenocara/app/xenodm/xenodm/auth.c:798

> 
> I strongly disagree with the pattern ".Xauth*".  It should be EXACT.  If
> someone else creates a file called .Xauthsadflkjdsaf, it should not be
> deleted.
> 
> As a final point, is this strategy of considering /tmp a safe place acceptable
> at all?  If $HOME doesn't work, why not just have X fail to work correctly
> and consider this "fail over to /tmp" a junk idea from the past?

The backup dir can be configured to something else, but it needs to be
writeable by the user whois login in. It could be a subdir of /tmp (if
the rc.d script takes care of creating it) or I can remove that
feature from xenodm and fail the login if /home is not writeable.

-- 
Matthieu Herrb

Reply via email to