[lkml]   [2007]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

    --- Jeremy Maitin-Shepard <> wrote:

    > Casey Schaufler <> writes:
    > > On Fedora zcat, gzip and gunzip are all links to the same file.
    > > I can imagine (although it is a bit of a stretch) allowing a set
    > > of users access to gunzip but not gzip (or the other way around).
    > > There are probably more sophisticated programs that have different
    > > behavior based on the name they're invoked by that would provide
    > > a more compelling arguement, assuming of course that you buy into
    > > the behavior-based-on-name scheme. What I think I'm suggesting is
    > > that AppArmor might be useful in addressing the fact that a file
    > > with multiple hard links is necessarily constrained to have the
    > > same access control on each of those names. That assumes one
    > > believes that such behavior is flawwed, and I'm not going to try
    > > to argue that. The question was about an example, and there is one.
    > This doesn't work. The behavior depends on argv[0], which is not
    > necessarily the same as the name of the file.

    Sorry, but I don't understand your objection. If AppArmor is configured
    to allow everyone access to /bin/gzip but only some people access to
    /bin/gunzip and (important detail) the single binary uses argv[0]
    as documented and (another important detail) there aren't other links
    named gunzip to the binary (ok, that's lots of if's) you should be fine.
    I suppose you could make a shell that lies to exec, but the AppArmor
    code could certainly check for that in exec by enforcing the argv[0]
    convention. It would be perfectly reasonable for a system that is so
    dependent on pathnames to require that.

    Casey Schaufler
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-25 19:47    [W:0.022 / U:37.316 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site