Re: Does Microsoft lie about the Linux features?

From: Erik Funkenbusch (erik_at_despam-funkenbusch.com)
Date: 09/21/03 

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.

Relevant Pages

  • Re: Does Microsoft lie about the Linux features?
    ... >> One way would be for root to take ownership. ... > If no delete privs exist, how would the backup account clean out the old ... Deny rights take precedence over Allow rights. ...
    (comp.os.linux.hardware)
  • Re: Does Microsoft lie about the Linux features?
    ... >> One way would be for root to take ownership. ... > If no delete privs exist, how would the backup account clean out the old ... Deny rights take precedence over Allow rights. ...
    (comp.os.linux.misc)
  • [Summary] ufsdump, solaris 9 & RBAC not working correctly
    ... server, and I don't want to have root logging in on the remote server, I ... etc. and key exchange setup for backup user. ... ufsdump, solaris 9 & RBAC not working correctly ... I thought suid was suid. ...
    (SunManagers)
  • Re: copy server to server retaining chmod and ownership?
    ... You must at least be root if you expect to be able to ... I realize that without using root, there's no way to maintain ownership ... Again though, with root ssh login disabled, permission denied. ... > Of course you can - you can tar it to stdout. ...
    (comp.os.linux.misc)
  • Re: FC2 granting rw on FAT32 dir [solved]
    ... James Wilkinson wrote: ... > Duncan Lithgow wrote: ... > ownership on FAT32: Windows pretends there is, sometimes, but there's ... > nothing for root or anyone to change on the disk. ...
    (Fedora)