Matthieu Herrb <matth...@herrb.eu> wrote: > 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.
My question is more basic: Why must there be a backup dir. Why not just fail hard. Should we change ssh so that if the home directory is non-readable, it store ssh keys and other ephmeral information in /tmp? No surely not. So why does X need to follow this pattern? Is there a strong justification, or is it simply a decision made 30 years ago?
