Re: Does Microsoft lie about the Linux features?
From: Erik Funkenbusch (erik_at_despam-funkenbusch.com)
Date: 09/21/03
- Next message: D.Stender: "Compile xine-dvdnav help please"
- Previous message: Jim Richardson: "Re: Does Microsoft lie about the Linux features?"
- In reply to: Jim Richardson: "Re: Does Microsoft lie about the Linux features?"
- Next in thread: Jim Richardson: "Re: Does Microsoft lie about the Linux features?"
- Reply: Jim Richardson: "Re: Does Microsoft lie about the Linux features?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 21 Sep 2003 09:02:42 GMT
On Sun, 21 Sep 2003 00:14:16 -0700, Jim Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, 21 Sep 2003 06:25:46 GMT,
> Erik Funkenbusch <erik@despam-funkenbusch.com> wrote:
>> On Sat, 20 Sep 2003 19:17:03 -0700, Jim Richardson wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Sat, 20 Sep 2003 19:07:28 GMT,
>>> Erik Funkenbusch <erik@despam-funkenbusch.com> wrote:
>>>> On Sat, 20 Sep 2003 17:49:27 GMT, Les Mikesell wrote:
>>>>
>>>>>>"Lew Pitcher" <lpitcher@sympatico.ca> wrote in message
>>>>> news:5bhgkb.kim.ln@merlin.l6s4x6-4.ca...
>>>>>
>>>>>> Having said all that, I concur that ACLs give a wider and more granular
>>>>>> control over access rights than the Unix permission bits do.
>>>>>
>>>>> People keep saying this, but I've never figured out how to use windows
>>>>> ACLs to get the permissions that you usually want on a shared space
>>>>> and that the unix 'sticky bit' gives automatically. That is, how do you
>>>>> get a setting that lets anyone in the group allowed there create new files
>>>>> but subsequently only the user that created a file is allowed to delete it,
>>>>> with r/w access by others optional and controlled by the owner.
>>>>
>>>> If you make a directory without delete attributes, then nobody can delete
>>>> the file except for the files owner, the person that created it.
>>>
>>> How does root go about clearing out the cruft then? Like cronjobs
>>> cleaning up /tmp?
>>
>> One way would be for root to take ownership. Another would be to run the
>> job as an account with "backup" priviledges.
>
> If no delete privs exist, how would the backup account clean out the old
> cruft?
The backup priviledge must have the right to read and write (and delete and
create) files it doesn't own or otherwise have permission to access,
otherwise backups wouldn't work.
> Using the root method, you'd have to take ownership, and then delete the
> files? seems kinda clunky. Can't you just give delete perms to root
> and the owner only? after all, that's what you get with the sticky bit,
> automatically.
Deny rights take precedence over Allow rights. If you deny everyone, then
that includes administrators unless they take ownership, even if you have a
specific "allow" delete permission.
You'd have to Deny some group that Administrators don't belong to in order
to accomplish this.
- Next message: D.Stender: "Compile xine-dvdnav help please"
- Previous message: Jim Richardson: "Re: Does Microsoft lie about the Linux features?"
- In reply to: Jim Richardson: "Re: Does Microsoft lie about the Linux features?"
- Next in thread: Jim Richardson: "Re: Does Microsoft lie about the Linux features?"
- Reply: Jim Richardson: "Re: Does Microsoft lie about the Linux features?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
