From: Bill Crawford <billc@netcomuk.co.uk>
To: vda <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux-kernel-daily-digest digest, Vol 1 #171 - 281 msgs
Date: Wed, 21 Nov 2001 15:18:29 +0000 [thread overview]
Message-ID: <3BFBC5C5.82366455@netcomuk.co.uk> (raw)
In-Reply-To: <200111201202.fAKC2Md29689@lists.us.dell.com> <3BFA8AE2.2B5FA0@netcomuk.co.uk> <01112112032600.01961@nemo>
vda wrote:
> > Perhaps we should not distinguish between read and execute on programs
> > either? After all, they're not much different, are they?
This was intended to be sarcastic :o)
> Yes, we can. In fact, NT lives with it with no problem. It is very common
> in NT to have rx on all readable files regardless of their 'executability'.
> If someone have 'r' perms, he can make a copy of a file, flag it with x and
> execute.
In theory one can do just that on Un*x systems too. That's why setid
bits can't be set by just anybody.
What if the program is setuid and executable by a group but not other?
We do this with "su" on servers.
Now, ACLs I want to see widely supported on Linux, and *used* properly
too. They've been little used in most environments I've seen even on
systems that do support them, which is a shame as they are a necessary
and useful idea. Yes, the Un*x permissions system does have some
limitations, but let's not break *all* the existing software and OSs
that use them, since what you're suggesting will not improve things.
> versions of it). It's too late. I've made patch for chmod which adds new +R
> flag to that effect.
Why is that needed anyway? By default directories get execute bit set
when they're created, at least in my environment; if you're extending
permissions you can use "go=u" or "o=g" to broaden the permissions, as
I would expect the existing perms to be correct on files vs directories
in most cases.
> --
> vda
--
/* Bill Crawford, Unix Systems Developer, Ebone (formerly GTS Netcom) */
#include <stddiscl>
const char *addresses[] = {
"bill@syseng.netcom.net.uk", "Bill.Crawford@ebone.com", // work
"billc@netcomuk.co.uk", "bill@eb0ne.net" // home
};
next parent reply other threads:[~2001-11-21 15:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200111201202.fAKC2Md29689@lists.us.dell.com>
[not found] ` <3BFA8AE2.2B5FA0@netcomuk.co.uk>
[not found] ` <01112112032600.01961@nemo>
2001-11-21 15:18 ` Bill Crawford [this message]
2001-11-21 17:39 ` Linux-kernel-daily-digest digest, Vol 1 #171 - 281 msgs vda
2001-11-21 18:13 ` Bill Crawford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BFBC5C5.82366455@netcomuk.co.uk \
--to=billc@netcomuk.co.uk \
--cc=bill@eb0ne.net \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.