On Mon, Feb 05, 2001 at 07:27:17PM -0800, Joey Hess wrote:
>Argh, egg on face: linux lets the owner of a file modify it even if it
>is mode 444 and in a directory they do not own. Yuck! Is this standard
>unix semantics? It sucks.
Standard Unix semantics prevents non-root users from writing to file
> "Massimo" == Massimo Dal Zotto <[EMAIL PROTECTED]> writes:
Massimo> chattr +i ?
Interesting point. Programs/packages shouldn't rely on it working all
the time though, as I doubt it is (yet) supported on NFS, resierfs,
Hurd, etc.
--
Brian May <[EMAIL PROTECTED]>
> Argh, egg on face: linux lets the owner of a file modify it even if it
> is mode 444 and in a directory they do not own. Yuck! Is this standard
> unix semantics? It sucks.
>
> --
> see shy jo
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? C
On Tue, Feb 06, 2001 at 10:12:00PM -0600, Chris Lawrence wrote:
> Then again, if the software can run as a non-root user and be suid to
> that user, I can't think of any good reason why it couldn't just be
> sgid to some group without any users in it instead. Maybe I'm not
> thinking hard enough t
> "s" == s Lichtmaier writes:
s> It's tricky... capabilities don't fix this.
I was considering the case where setuid root may not be required
because capabilities could be used instead.
s> And I know nothing about ACL's on UNIX systems. It must be
s> something like "these user
> s> A better design would have been having the file to have a
> s> second UID/GID.
>
> s> So, a file could be owned by root, but setuid man.
>
> ACLs and capabilities are probably two very different solutions to
> this problem.
>
> (...depends on how they are implemented).
It's
On Feb 07, Nicol?s Lichtmaier wrote:
> > > Argh, egg on face: linux lets the owner of a file modify it even if it
> > > is mode 444 and in a directory they do not own. Yuck! Is this standard
> > > unix semantics? It sucks.
> > Even worse: IIRC the owner of a file can chmod it to his or her
> > hear
> "s" == s Lichtmaier writes:
s> A better design would have been having the file to have a
s> second UID/GID.
s> So, a file could be owned by root, but setuid man.
ACLs and capabilities are probably two very different solutions to
this problem.
(...depends on how they are im
> > Argh, egg on face: linux lets the owner of a file modify it even if it
> > is mode 444 and in a directory they do not own. Yuck! Is this standard
> > unix semantics? It sucks.
> Even worse: IIRC the owner of a file can chmod it to his or her
> heart's content, and this is standard Unix semantic
On Mon, Feb 05, 2001 at 09:41:00PM -0600, Chris Lawrence wrote:
> On Feb 05, Joey Hess wrote:
> > Argh, egg on face: linux lets the owner of a file modify it even if it
> > is mode 444 and in a directory they do not own. Yuck! Is this standard
> > unix semantics? It sucks.
>
> Even worse: IIRC the
On Feb 05, Joey Hess wrote:
> Argh, egg on face: linux lets the owner of a file modify it even if it
> is mode 444 and in a directory they do not own. Yuck! Is this standard
> unix semantics? It sucks.
Even worse: IIRC the owner of a file can chmod it to his or her
heart's content, and this is sta
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> Argh, egg on face: linux lets the owner of a file modify it
Joey> even if it is mode 444 and in a directory they do not
Joey> own. Yuck! Is this standard unix semantics? It sucks.
The directory is irrelevant - you are not cha
Argh, egg on face: linux lets the owner of a file modify it even if it
is mode 444 and in a directory they do not own. Yuck! Is this standard
unix semantics? It sucks.
--
see shy jo
This post to bugtraq raises an interesting point. If we have a suid
executable (not suid root), it is really silly to let the user it is
suid to write to it, since this gives an attacker a guarenteed way to
get a trojan onto the system if they manage to exploit a hole in the
program. Instead of mod
14 matches
Mail list logo
