chattr immutable

Hi,

I have a FC4 box with a Samba 3.014. There is one large share
configured. I wanted to make a folder within that share un-deleteable
but also allow smb users to write files to the folder. I tried

mkdir myfolder; chmod 777 myyfolder; chattr +i myfolder

Then from a windows box tried to delete the folder and got permissions
denied, so far so good. They I tried to copy a file to the folder and
was denied also, not so good.

I have tried a combinations of +i +a but I can't get the desired effect.
Is what I am attempting possible or should I create a new share and use
smb.conf to administer the file permissions?

TIA,
Dp.


--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: chattr immutable

What does your smb.conf look like?

Kind regards,

Herta

2009/2/16 Dermot Paikkos
>
> Hi,
>
> I have a FC4 box with a Samba 3.014. There is one large share
> configured. I wanted to make a folder within that share un-deleteable
> but also allow smb users to write files to the folder. I tried
>
> mkdir myfolder; chmod 777 myyfolder; chattr +i myfolder
>
> Then from a windows box tried to delete the folder and got permissions
> denied, so far so good. They I tried to copy a file to the folder and
> was denied also, not so good.
>
> I have tried a combinations of +i +a but I can't get the desired effect.
> Is what I am attempting possible or should I create a new share and use
> smb.conf to administer the file permissions?
>
> TIA,
> Dp.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html



--
"Life on Earth may be expensive,
but it comes with a free ride around the Sun."
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: chattr immutable

Dermot Paikkos wrote:

> I have a FC4 box with a Samba 3.014. There is one large share
> configured. I wanted to make a folder within that share un-deleteable
> but also allow smb users to write files to the folder. I tried
>
> mkdir myfolder; chmod 777 myyfolder; chattr +i myfolder
>
> Then from a windows box tried to delete the folder and got permissions
> denied, so far so good. They I tried to copy a file to the folder and
> was denied also, not so good.
>
> I have tried a combinations of +i +a but I can't get the desired effect.
> Is what I am attempting possible or should I create a new share and use
> smb.conf to administer the file permissions?

1. "chattr +i" is a blunt instrument; once set, the file or directory
is completely immutable.

2. "chattr +a" doesn't allow appends; it denies everything except
appends, so "chattr +a +i" is equivalent to just "chattr +i".

3. Modifying a directory isn't an "append", so "chattr +a" isn't
useful here.

If filesystem permissions cannot be used (e.g. because both the
directory and its parent need to be writable by the user), you can
still prevent the directory from being deleted by adding a file or
subdirectory which the user cannot delete.

One option is to add a subdirectory, owned by root, writable only by
root, and containing at least one file. The user won't be able to
delete the file as they don't have write permission on the
subdirectory, and a non-empty directory cannot be deleted.

Another option is to just add a file within the directory and use
"chattr +i" on the file.

--
Glynn Clements
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: chattr immutable

> Dermot Paikkos wrote:
> >
> > mkdir myfolder; chmod 777 myyfolder; chattr +i myfolder
> >
> > Then from a windows box tried to delete the folder and got
> permissions
> > denied, so far so good. They I tried to copy a file to the folder
and
> > was denied also, not so good.
> >
> > I have tried a combinations of +i +a but I can't get the desired
> effect.
> > Is what I am attempting possible or should I create a new share and
> use
> > smb.conf to administer the file permissions?
>
> 1. "chattr +i" is a blunt instrument; once set, the file or directory
> is completely immutable.
>
> 2. "chattr +a" doesn't allow appends; it denies everything except
> appends, so "chattr +a +i" is equivalent to just "chattr +i".
>
> 3. Modifying a directory isn't an "append", so "chattr +a" isn't
> useful here.
>
> If filesystem permissions cannot be used (e.g. because both the
> directory and its parent need to be writable by the user), you can
> still prevent the directory from being deleted by adding a file or
> subdirectory which the user cannot delete.
>
> One option is to add a subdirectory, owned by root, writable only by
> root, and containing at least one file. The user won't be able to
> delete the file as they don't have write permission on the
> subdirectory, and a non-empty directory cannot be deleted.
>
> Another option is to just add a file within the directory and use
> "chattr +i" on the file.


One of the other things I was hoping to do was deny users from renaming
the folder or the other classic mistake, accidently drag and drop a
folder into another folder.

I can't think of a set of UNIX permission or smb.conf directives that is
going to allow make a directory readonly but allow a group to create
files within the directory.

Thanx for the suggestions though. They will have to do.

Dp.






--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: chattr immutable

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
-------firegpg074eqfr9l4m8bfgin5c9jc
Content-Type: text/plain; format=flowed; charset=UTF-8
Content-Transfer-Encoding: base64

MjAwOS8yLzE2IERlcm1vdCBQYWlra29zIDxEZXJtb3QuUGFpa2tvc0BzY2ll bmNlcGhvdG8uY28u
dWs+Og0KPj4gRGVybW90IFBhaWtrb3Mgd3JvdGU6DQo+PiA+DQo+PiA+IG1r ZGlyIG15Zm9sZGVy
OyBjaG1vZCA3NzcgbXl5Zm9sZGVyOyBjaGF0dHIgK2kgbXlmb2xkZXINCj4+ ID4NCj4+ID4gVGhl
biBmcm9tIGEgd2luZG93cyBib3ggdHJpZWQgdG8gZGVsZXRlIHRoZSBmb2xk ZXIgYW5kIGdvdA0K
Pj4gcGVybWlzc2lvbnMNCj4+ID4gZGVuaWVkLCBzbyBmYXIgc28gZ29vZC4g VGhleSBJIHRyaWVk
IHRvIGNvcHkgYSBmaWxlIHRvIHRoZSBmb2xkZXINCj4gYW5kDQo+PiA+IHdh cyBkZW5pZWQgYWxz
bywgbm90IHNvIGdvb2QuDQo+PiA+DQo+PiA+IEkgaGF2ZSB0cmllZCBhIGNv bWJpbmF0aW9ucyBv
ZiAraSArYSBidXQgSSBjYW4ndCBnZXQgdGhlIGRlc2lyZWQNCj4+IGVmZmVj dC4NCj4+ID4gSXMg
d2hhdCBJIGFtIGF0dGVtcHRpbmcgcG9zc2libGUgb3Igc2hvdWxkIEkgY3Jl YXRlIGEgbmV3IHNo
YXJlIGFuZA0KPj4gdXNlDQo+PiA+IHNtYi5jb25mIHRvIGFkbWluaXN0ZXIg dGhlIGZpbGUgcGVy
bWlzc2lvbnM/DQoNCkknbSBwcmVzdW1pbmcgdGhhdCB5b3VyIHVzZXJzIGhh dmUgd3JpdGUgcGVy
bWlzc2lvbiBvbiB0aGUgcm9vdCBvZiB0aGUgc2hhcmUsIG90aGVyd2lzZSB0 aGV5IHdvdWxkbid0
IGJlIGFibGUgdG8gZGVsZXRlIHRoZSBzdWItZGlyZWN0b3J5IGluIHRoZSBm aXJzdCBwbGFjZS4g
SWYgdGhpcyBpcyB0aGUgY2FzZSwgeW91IGNvdWxkIHVzZSB0aGUgcmVzdHJp Y3RlZCBkZWxldGUg
YXR0cmlidXRlIChzZWUgbWFuIGNobW9kKSBvbiB0aGUgcGFyZW50IGRpcmVj dG9yeSAod2l0aCB3
b3JsZCB3cml0ZSkgYW5kIHRoZW4gbWFrZSB0aGUgc2hhcmVkIG5vbi1kZWxl dGFibGUgc3ViLWRp
cmVjdG9yeSBvd25lZCBieSByb290LCB3aXRoIHdvcmxkIHdyaXRlLiBUaGlz IGJhc2ljYWxseSBw
cmV2ZW50cyB1c2VycyBmcm9tIGRlbGV0aW5nIGZpbGVzIHRoYXQgYXJlbid0 IG93bmVkIGJ5IHRo
ZW0sIHNvIGFzIGxvbmcgYXMgdGhlIHN1Yi1kaXJlY3RvcnkgaXMgb3duZWQg Ynkgcm9vdCwgb25s
eSByb290IGNhbiBkZWxldGUgaXQuIFRoaXMgaXMgdGhlIHdheSB0aGUgL3Rt cCBkaXJlY3Rvcnkg
d29ya3MuIFRoaXMgaXMgaG93IHlvdSB3b3VsZCBuZWVkIHRvIGNyZWF0ZSB5 b3VyIHNoYXJlcyAo
cnVuIGFzIHJvb3QpOg0KDQpta2RpciAvb3B0L215X3NoYXJlDQpjaG1vZCAx Nzc3IC9vcHQvbXlf
c2hhcmUNCm1rZGlyIC9vcHQvbXlfc2hhcmUvc3ViX3NoYXJlDQpjaG1vZCAx Nzc3IC9vcHQvbXlf
c2hhcmUvc3ViX3NoYXJlDQoNCk5vdGUgdGhhdCBJIGhhdmUgYWxzbyBhZGRl ZCB0aGUgcmVzdHJp
Y3RlZCBkZWxldGlvbiBiaXQgdG8gdGhlIHN1Yl9zaGFyZS4gSWYgeW91IHdh bnQgdG8gbGV0IHVz
ZXJzIGRlbGV0ZSBlYWNoIG90aGVycyBmaWxlcyBpbnNpZGUgdGhhdCBkaXJl Y3RvcnksIHlvdSBj
YW4gb21pdCB0aGUgMSBhdCB0aGUgYmVnaW5uaW5nICg3NzcpLg0KDQpJIGhh dmVuJ3QgdGVzdGVk
IGFueSBvZiB0aGlzIG92ZXIgYSBzYW1iYSBzaGFyZSwgYnV0IEkgZG9uJ3Qg c2VlIHdoeSBpdCB3
b3VsZG4ndCB3b3JrIHRoZXJlIHRvby4NCg0KSG9wZSBJIGhhdmUgdW5kZXJz dG9vZCB5b3UgY29y
cmVjdGx5Lg0KDQpDaGVlcnMNCg0KQWRhbQ==
-------firegpg074eqfr9l4m8bfgin5c9jc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.4)

iEYEARECAAYFAkmZySoACgkQfNJVASeK9ui4fQCdHre0wefc66qRpzTbnkZL uvcp
qnQAn39Ftb17vOz4u3oIu7M/lHq8JeRx
=v6ke
-----END PGP SIGNATURE-----

-------firegpg074eqfr9l4m8bfgin5c9jc--

--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: chattr immutable

Dermot Paikkos wrote:

> One of the other things I was hoping to do was deny users from renaming
> the folder or the other classic mistake, accidently drag and drop a
> folder into another folder.

Create, move, rename and delete are determined by the permissions on
the containing directory. It isn't possible to set different
restrictions for different files or subdirectories within a given
directory, nor allow creation but forbid deletion.

The only exception is that if the directory has the sticky bit set
(chmod +t), users cannot move, rename or delete a file or subdirectory
which they do not own.

If the user owns the directory, they can clear this flag, but that may
not be an issue if you're simply trying to prevent accidents rather
than deliberate acts.

However, it may prove problematic if there are plausible scenarios in
which files owned by another user can end up in the directory, as you
can end up with files which can only be removed by root.

> I can't think of a set of UNIX permission or smb.conf directives that is
> going to allow make a directory readonly but allow a group to create
> files within the directory.

Creating files within a directory directly contradicts the notion of
"read only".

You can get slightly more flexibility if you use POSIX ACLs rather
than the historical ugo/rwx permission model. You're still limited to
read/write/execute permission, but you can assign permissions to
multiple named users and to multiple named groups.

Also, Samba has a variety of configuration options which allow the
Unix permission model to be bypassed. E.g. the "dos filemode" option
allows any user with write permission on a file or directory to change
the permissions and/or owner.

--
Glynn Clements
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: chattr immutable

> -----Original Message-----
>
> mkdir /opt/my_share
> chmod 1777 /opt/my_share
> mkdir /opt/my_share/sub_share
> chmod 1777 /opt/my_share/sub_share
>
> Note that I have also added the restricted deletion bit to the
> sub_share. If you want to let users delete each others files inside
> that directory, you can omit the 1 at the beginning (777).
>
> I haven't tested any of this over a samba share, but I don't see why
it
> wouldn't work there too.
>
> Hope I have understood you correctly.

Yes I did and it achieves exactly what I want. The top level folder
(within the share) cannot be renamed, deleted or moved but everyone can
write to the folder.

I have always had the "traditional view" of the sticky bit. I thought it
was was just for excutable. Wikpedia has a nice "usage" section on
Sticky bit.

Thanx Adam and Glynn. That was really useful.
Dp.


--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html