From: Tomas Volf <~@wolfsden.cz>
To: Fabio Natali <me@fabionatali.com>
Cc: 68289@debbugs.gnu.org
Subject: [bug#68289] [PATCH] services: xorg: Add xorg-start-command-xinit procedure.
Date: Thu, 18 Apr 2024 23:09:56 +0200 [thread overview]
Message-ID: <ZiGMJGQfxqSvXyjF@ws> (raw)
In-Reply-To: <87r0f4l4kb.fsf@fabionatali.com>
[-- Attachment #1: Type: text/plain, Size: 3139 bytes --]
Hello Fabio,
first, let me thank you for the review, and apologize for somewhat late
response, sadly I have been busy.
On 2024-04-17 10:30:12 +0100, Fabio Natali wrote:
> Hi, a quick follow-up on a couple of points.
>
> On 2024-04-16, 19:29 +0100, Fabio Natali <me@fabionatali.com> wrote:
> > - I haven't tested the patch on my system yet, but I plan to do it
> > soon.
>
> I've tested the patch and it works as expected on my system.
Great! :)
>
> > `(determine-vty)' is similar to the block below, but `startx' relies
> > on the `tty' command from Coreutils. Do you think there might be any
> > advantage in using it in `(determine-vty)'? A slight simplification
> > perhaps?
>
> Looking into this more closely, the `tty' command wouldn't be a
> simplification. It might be a bit more consistent with other parts of
> the patch and it'd abstract away the hardcoded `/proc/self/fd/0', but
> probably not worth the change?
I think the current way is fine, since this is Guix specific code, so it does
not have to be extremely portable. But that is just my opinion. Would be nice
to know if it works on Hurd.
>
> > The patch saves the server's auth file in `/tmp' whereas `startx' uses
> > the home directory. I wonder if this might make any difference in
> > terms of security. Related, how can we be sure that `(mkstemp
> > "/tmp/serverauth.XXXXXX")' will be setting the right file permissions?
While POSIX does not seem to specify the permissions of the created file, the
Guile's manual is pretty clear regarding it:
POSIX doesn’t specify the permissions mode of the file. On GNU and
most systems it’s ‘#o600’; an application can use ‘chmod’ to relax
that if desired.
In my understanding that makes this usage safe.
>
> I see the reason why we want to use `/tmp', as otherwise the number of
> stale `serverauth.XXXXXX' files would grow indefinitely. Using `/tmp',
> at least we know they'll be garbage collected at every reboot. Any way
> to emulate `startx' and use some sort of `trap' to remove the file on
> exit?
Yes, the clean up was the main motivator. The script could *try* to clean up,
but even then it would leave garbage in the $HOME in situations like power
failure and kernel crashes. So using /tmp seems like simple yet reliable
solution.
>
> > Finally, on a purely cosmetic side, any reason to have `(define X
> > (xorg-wrapper config))' outside the G-expression, while the other
> > definitions are inside?
>
> Oh yes, the `(define X ...)' has to be outside the G-expression, of
> course.
>
> The security aspect (in relation to the server auth file, its
> permissions and location) is the only remaining point where I'd like an
> extra pair of eyes. The rest of the patch LGTM.
>
> There's a couple of microscopic formatting issues (e.g. an occurrence of
> tty where I'd write TTY instead), I'll list them all in a follow-up.
>
> Thanks, best wishes, Fabio.
Have a nice day,
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-04-18 21:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-06 15:07 [bug#68289] [PATCH] services: xorg: Add xorg-start-command-xinit procedure Tomas Volf
2024-04-16 18:29 ` Fabio Natali via Guix-patches via
2024-04-17 9:30 ` Fabio Natali via Guix-patches via
2024-04-18 18:43 ` Fabio Natali via Guix-patches via
2024-04-18 21:17 ` Tomas Volf
2024-04-18 21:09 ` Tomas Volf [this message]
2024-04-19 12:25 ` Fabio Natali via Guix-patches via
2024-04-24 11:59 ` Fabio Natali via Guix-patches via
2024-04-24 17:43 ` Tomas Volf
2024-05-02 9:55 ` Ludovic Courtès
2024-05-02 14:58 ` Tomas Volf
2024-05-03 9:57 ` Ludovic Courtès
2024-05-11 13:29 ` Tomas Volf
2024-05-11 13:26 ` [bug#68289] [PATCH v2 1/3] " Tomas Volf
2024-05-11 13:26 ` [bug#68289] [PATCH v2 2/3] services: xorg: Add startx-command-service-type Tomas Volf
2024-05-11 13:26 ` [bug#68289] [PATCH v2 3/3] home: services: Add home-startx-command-service-type Tomas Volf
2024-05-30 17:33 ` [bug#68289] [PATCH] services: xorg: Add xorg-start-command-xinit procedure Arun Isaac
2024-05-30 18:27 ` Tomas Volf
2024-05-30 18:18 ` [bug#68289] [PATCH v3 1/2] services: xorg: Add startx-command-service-type Tomas Volf
2024-05-30 18:18 ` [bug#68289] [PATCH v3 2/2] home: services: Add home-startx-command-service-type Tomas Volf
2024-05-30 18:29 ` [bug#68289] [PATCH v4 1/2] services: xorg: Add startx-command-service-type Tomas Volf
2024-05-30 18:29 ` [bug#68289] [PATCH v4 2/2] home: services: Add home-startx-command-service-type Tomas Volf
2024-05-30 21:43 ` bug#68289: [PATCH] services: xorg: Add xorg-start-command-xinit procedure Arun Isaac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZiGMJGQfxqSvXyjF@ws \
--to=~@wolfsden.cz \
--cc=68289@debbugs.gnu.org \
--cc=me@fabionatali.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).