сб, 6 мар. 2021 г. в 20:41, Matthieu Herrb <matth...@herrb.eu>: > > 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 ?
Well, I do... nothing? I can show my .xsession, there's nothing special. I run cwm, FWIW, and do not start anything heavy from the beginning, to have a working desktop ASAP. KDE and GNOME won't work this way for sure. :-) For .xsession-errors, there is /tmp-based handling in /etc/X11/xenodm/Xsession already. Oh, now I know where the disk space on /tmp gets lost from time to time... > > > 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. I've sent a diff for subdir of /tmp already. ;-) -- WBR, Vadim Zhukov
