lmi
[Top][All Lists]
Advanced

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

Re: [lmi] ZOMG selinux


From: Vadim Zeitlin
Subject: Re: [lmi] ZOMG selinux
Date: Sun, 31 Oct 2021 01:34:20 +0200

On Sat, 30 Oct 2021 22:59:25 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2/8/20 11:32 PM, Greg Chicares wrote:
GC> > [Posted for historical reasons. The problem may already be resolved.]
GC> 
GC> To my dismay, this search:
GC>   https://www.google.com/search?q=%22failed+to+change+to+directory+%2Ftmp%22
GC> led to the message I'm replying to. If its author could help,
GC> I wouldn't be searching the web.

 I really hate when this happens.

GC> Today's problem looks similar (the same 'schroot' command fails,
GC> but the classic permissions are 777, so the cause is different:
GC> 
GC>   $ls -ld /srv/chroot/lmi_bookworm_4/tmp
GC>   ls: cannot access /srv/chroot/lmi_bookworm_4/tmp: Permission denied
GC> 
GC>   $sudo ls -ld /srv/chroot/lmi_bookworm_4/tmp
GC>   drwxrwxrwt. 3 root root 4096 Oct 30 11:59 /srv/chroot/lmi_bookworm_4/tmp

 Sorry for a stupid question, but have you checked the permissions on the
intermediate directories, i.e. /src/chroot and /src/chroot/lmi_bookworm_4
(the standard /srv permissions should be open enough to allow access to its
subdirectories)?

GC> Examining the permissions:
GC> 
GC>   - drwxr-xr-x
GC>   + drwxrwxrwt.
GC> 
GC> ...I don't see how the 't' sticky bit could be the problem, especially
GC> because it's set on my personal machine, where everything just works:
GC> 
GC>   $ls -ld /srv/chroot/lmi_bookworm_4/tmp      
GC>   drwxrwxrwt 7 root root 12288 Oct 28 20:56 /srv/chroot/lmi_bookworm_4/tmp
GC> 
GC> ...so that leaves the selinux '.' suffix. The selinux context is:
GC> 
GC>   $sudo ls -ldZ /srv/chroot/lmi_bookworm_4/tmp
GC>   drwxrwxrwx. root root unconfined_u:object_r:tmp_t:s0   
/srv/chroot/lmi_bookworm_4/tmp
GC> 
GC> Vadim, can you suggest an appropriate way to address this?

 Right now I can't, sorry. I don't know much about SELinux and from what
little I know it looks like it shouldn't be disallowing access to this
directory based on the context shown above. But I could well be wrong
because I really don't know enough about it. I'd still like to ask, just in
case, about the output of "id -Z" command for your normal user and for the
SELinux context of some directory you do have access to, e.g. /srv itself.
What does it look like and does it differ from the context for this one?

GC> I initially hoped that '/tmp' was considered exceptionally
GC> dangerous, and using '/opt/lmi/tmp' would sidestep the
GC> difficulty; but my normal user can't access even its own
GC> home directory inside that chroot, so I'm wondering whether
GC> I need to make time for a deep dive into selinux.

 I'm afraid this might well be the case... I could try looking more into it
too, but I won't be able to do it until Monday at the earliest and I'd have
to configure it on some test system first, as I still don't use it myself
(although I've been thinking since quite some time that I probably ought
to).

 Sorry for lack of help,
VZ

Attachment: pgpgDnkFy4zvM.pgp
Description: PGP signature


reply via email to

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