public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
};

       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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox