linux-kernel - Re: [PATCH] 9p: attach-per-user

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 13 Sep 2007 09:20:23 -0500
From:	"Eric Van Hensbergen" <ericvh@...il.com>
To:	"Latchesar Ionkov" <lucho@...kov.net>
Cc:	linux-kernel@...r.kernel.org, v9fs-developer@...ts.sourceforge.net,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] 9p: attach-per-user

On 9/12/07, Latchesar Ionkov <lucho@...kov.net> wrote:
>
> - allow only one user to access the tree (access=<uid>)
>  Only the user with uid can access the v9fs tree. Other users that attempt
>  to access it will get EPERM error.
>

While access=<uid> and dfltuid=<some-other-uid> creates an interesting
flexibility in the way things can be used, I'm wondering if
access=<uid> dfltuid=DEFAULT_UID is intuitive, it might be nice for
the default behavior to be setting defltuid to the uid specified in
access when that access option is used.  This can be overridden with
the dfltuid option, but I think it makes more sense to attach as the
uid you are restricting access to.

If that's the way we want to go, I think that can be handled in a
separate patch.

I've merged this stuff into my test tree, as soon as regressions pass
and I confirm they compile clean on another architecture I'll push
them into my devel to be picked up by -mm.

                 -eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/