сб, 6 мар. 2021 г. в 20:50, Theo de Raadt <dera...@openbsd.org>: > > 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.
But you can still log in to read-only home via SSH. > So why does X need to follow this pattern? Is there a strong justification, > or is it simply a decision made 30 years ago? I feel myself having too little experience to judge. But: previously I used "startx" and I was happy to type "mrw /home; startx" after logging in (mrw is small script doing mount -uorw). Then startx was broken and now I'm forced to use xenodm. So I have it enabled, and I log in graphically from the start. If we'll drop /tmp failover, I'll have to switch consoles and log in to text console in addition. Not a big deal, of course. -- WBR, Vadim Zhukov
