guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#73925] [PATCH] add access control to daemon socket in shepherd serv


From: Reepca Russelstein
Subject: [bug#73925] [PATCH] add access control to daemon socket in shepherd service
Date: Fri, 25 Oct 2024 19:10:32 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Ludovic Courtès <ludo@gnu.org> writes:

>> +                  ;; Ensure that a fresh directory is used, in case the old
>> +                  ;; one was more permissive and processes have a file
>> +                  ;; descriptor referencing it hanging around, ready to use
>> +                  ;; with openat.
>> +                  (false-if-exception
>> +                   (delete-file-recursively "/var/guix/daemon-socket"))
>> +                  (let ((perms #$(logand socket-directory-perms
>> +                                         (lognot #o022))))
>> +                    (mkdir "/var/guix/daemon-socket" perms)
>> +                    ;; Override umask
>> +                    (chmod "/var/guix/daemon-socket" perms))
>
> Speaking of ‘openat’, maybe use ‘mkdir-p/perms’ instead of doing it in
> two steps?

PERMS is passed directly to mkdir; the umask may cause the permissions
the directory is created with to be less permissive than those, but
never more.  The only reason I call chmod here is because the umask may
happen to be more strict than PERMS.  mkdir-p/perms creates the
directory with the permissions initially restricted only by the umask,
then later chmods it in a separate step, leaving a window during which
the directory is likely world-executable and world-readable.  So while
mkdir-p/perms would be an improvement on the "make sure no components
are symlinks" front, it would be a downgrade in restricting access to
the directory.

This behavior can be remedied by ensuring that the final call to
'mkdirat' passes in the specified permission bits.  I've submitted a
patch to do this in issue #74002.

There's also a minor annoyance in that the 'owner' argument that
mkdir-p/perms wants MUST be a passwd object.  This means that the uid
and gid to use can't be specified independently, nor can they be
specified as -1 or 0, you *have* to do (getpwnam "root") or something
similar.

For now I'm going to keep this part as-is, since currently using
mkdir-p/perms would neither make it more secure nor more concise.

The attached patch incorporates all the other changes you've mentioned.

- reepca

Attachment: 0001-services-guix-configuration-add-access-control-to-da.patch
Description: Text Data

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]