Re: [RFC] readlink()-related oddities

[David Howells]

Al Viro  wrote:

> All of them?  I see two kinds there - one is magical symlink (recognized
> by contents in afs_iget()), another is this autocell thing, the latter
> having no ->readlink().  Both serve as automount points, don't they?

The "autocell" thing is where you don't have an AFS file of that name and
lookup of that non-existent file as an attempt to mount a destination volume
encoded by the filename.

David
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] readlink()-related oddities

[Al Viro]

On Fri, Nov 20, 2015 at 09:59:05AM +, David Howells wrote:
> Al Viro  wrote:
> 
> > 3) normally, readlink(2) fails for non-symlinks.  Moreover, according to
> > POSIX it should do so (with -EINVAL).  There is a pathological case when
> > it succeeds for a directory, though.  Namely, one of the kinds of AFS
> > "mountpoints".
> 
> All AFS mountpoints are magic symlinks that are specially interpreted by the
> client as far as I'm aware.  I'm not sure why the designers didn't just select
> a different file type for them, but they didn't.

All of them?  I see two kinds there - one is magical symlink (recognized
by contents in afs_iget()), another is this autocell thing, the latter
having no ->readlink().  Both serve as automount points, don't they?

> > stat(2) reports those as directories, stepping into them leads to
> > automounting a directory there (why do we have ->open() for them, BTW?).
> 
> I think I put that in to make sure the open() syscall returned EREMOTE rather
> than another error if you tried to open it.  It can probably be removed
> because with the d_automount code you can't ever get there I think - unless
> you can pass AT_NO_AUTOMOUNT to openat().

Just how would openat() get the AT_... flags?  Only statat(2) accepts
AT_NO_AUTOMOUNT, sorry.
 
> > How the hell is userland supposed to guess to call readlink(2) on those
> > suckers to get the information of what'll get automounted there if we step
> > upon them?
> 
> There's an AFS userspace command that could be used to query a mountpoint that
> was going to use it.  However, I suspect readlink() will now always trigger
> the automount.  This is one of the things OpenAFS uses pioctl() for - but
> since I'm not allowed to add that to the kernel, I have to find some other way
> of doing it.

Well, pioctl() is a piec^H^Hle of shit interface; let's figure out what we'd
actually want to implement and do that.

One obvious thing is "here's a pathname, tell me what gets automounted here"
(with interesting question of what to do if the automount is being triggered
right now).  Another thing is locating those guys; if we had a separate file
type for them (i.e. could recognize them by st_mode _and_ d_type), we would
be fine (the usual tree-walkers would be able to spot such places and query
them for prospective automount targets), but without that... a syscall for
everything in a tree just to list those suckers?
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ANN: Experimental Fedora Rawhide kernels (selinux-next and audit-next)

[Paul Moore]

For the past few weeks I've been building experimental Fedora Rawhide kernels 
with all of the SELinux and audit kernel patches targeted for linux-next 
included. It has worked out reasonably well, and with the exception of getting 
a working Linux 4.4-rc1 build this week, it has proven to be relatively easy 
to manage. If you would like to help with testing and don't mind the 
instability that comes with development kernels, the Fedora COPR repository 
link is below.

I've been doing at least one build each week, sometimes more, and I expect to 
continue with that frequency. I also perform a quick sanity check on each 
successful build, including running the SELinux and audit testsuites; however, 
there may be times when the kernel is simply broken, so exercise caution and 
please don't run these kernels on anything critical.

 * https://copr.fedoraproject.org/coprs/pcmoore/kernel-secnext

-- 
paul moore
www.paul-moore.com

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: seccomp and audit_enabled

[Paul Moore]

On Fri, Nov 20, 2015 at 12:51 PM, Tony Jones  wrote:
> Any comments on this?  Current interaction between enabled_enabled and dummy 
> flag seems wrong to me.   I can code up
> a patch.

It's on my todo list for this development cycle, I've just been a
little busy lately with the merge window and now some -rc1 testing.

-- 
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html