On Wed, Oct 05, 2005 at 02:47:27PM -0400, Horst von Brand wrote:
> Luke Kenneth Casson Leighton <[email protected]> wrote:
> > On Wed, Oct 05, 2005 at 01:24:12PM +0400, Nikita Danilov wrote:
> > > Marc Perkel writes:
>
> > > [...]
> > >
> > > > Right - that's Unix "inside the box" thinking. The idea is to make the
> > > > operating system smarter so that the user doesn't have to deal with
> > > > what's computer friendly - but reather what makes sense to the user.
> > > > From a user's perspective if you have not rights to access a file then
> > > > why should you be allowed to delete it?
>
> > > Because in Unix a name is not an attribute of a file.
>
> > there is no excuse.
>
> It's not an excuse, it's part of a coherent view of how things work. Just
> as Netware used to have its, and DOS had its (sort of). As the world view
> underneath Unix, it is darn hard to "fix".
>
> [This discussion sounds quite a lot like it is /you/ who needs "fixing",
> i.e., first wrap your head around Unix' ways...]
asking "ordinary" people to do that is unrealistic: surely you know
that?
i just spent two hours helping a friend who wasn't familiar
with the concept of "give root password for maintenance or
press ctrl-d" they'd been pressing ctrl-d because it said so
and now i'm going to have a 5-hour round-trip journey and possibly
an overnight stay to sort out the mess.
> > selinux has already provided an alternative that is similar to NW
> > file permissions.
>
> Nope. SELinux provides MAC,
yes.
> i.e., mechanisms by which system-wide policy
> (not the random owner of an object) ultimately decides what operations to
> allow.
yes. the concept is not incompatible with what i said: the only bit
that is wrong with what you've said is the word "Nope".
> That is not "file permissions".
part of the coverage of the MAC is file and directory permissions, and
as i mentioned earlier, it so happens that each selinux permission
corresponds, i believe one-to-one, with a function in the dnode and
inode vfs higher-order-function tables in the linux kernel.
example permissions (from postfix.te, policy source version 18):
allow postfix_$1_t { sbin_t bin_t }:dir r_dir_perms;
allow postfix_$1_t { bin_t usr_t }:lnk_file { getattr read };
allow postfix_$1_t shell_exec_t:file rx_file_perms;
i am confident enough with selinux to say that those are file
and directory permissions.
(r_dir_perms is a macro that expands to directory read
permissions { read getattr lock search ioctl }, and
rx_file_perms is a macro that expands to { read getattr lock
execute ioctl })
what this is saying is that postfix_$whatever_t context is
allowed to read the contents of /sbin and /bin; it's also
allowed to know if symlinks in /bin and /usr actually exist,
and also allowed to follow those symlinks; and it's also allowed to
know if shell-scripts exist, and also to read and ultimately
execute them.
> And yes, this is quite un-Unix-like.
this is a good thing.
> [...]
>
> > in what way is it possible for linux to fully support the NTFS
> > filesystem?
>
> If you ask me, preferably not at all, just let that unholy mess quietly go
> the way of the dinosaurs. Sadly, interoperability is required at times,
> so...
*sigh*, tell me about it. well, when reactos gets its NTFS driver, i
will be sure to let you know. i promise :)
l.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
