Re: Can't hardlink in different dirs. (BUG#826)
Andrea Arcangeli <[EMAIL PROTECTED]> wrote: > For what exactly is it an handy feature? I never needed to hardlink to > a file that I don't own, so you would convince me if you would raise > good points. cp -la is rather handy when doing test builds. And you can easily wind up not owning the files if there's more than one person working on the project. -- Raul
Re: Can't hardlink in different dirs. (BUG#826)
Hi! > >The last time: your change does not increase security. Sigh... Andrea, > > You say again for the open(2) issue? As I just said the open(2) is > possible only due the lazyness of not having implemented revoke(2) yet. > > Just because fixing hardlinks is not enough it doesn't mean it's in the > wrong direction. revoke() is needed anyway (for /dev/vcsa, /dev/sound, /dev/fb0 for example), so I guess *) first implement revoke() *) then talk about this issue again I still think that adding feature to truncate file before deletion into rm would make you happy, Andrea. That handles both open() and link() cases nicely. Pavel PS: That new switch to rm looks really nice, think about it. -- I'm really [EMAIL PROTECTED] Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Re: Can't hardlink in different dirs. (BUG#826)
Hi! > But the fact that we don't have a working revoke() is the more important > problem. Forget local attacks. What about telnet to port 80, type GET > /~user/bigassgif.gif, and hit ^]^Z so the transfer will never finish? rm > needs some teeth for such situations. You don't need revoke() to do this. Just > ~user/bigassgif.gif; rm ~user/bigassgif.gif will work in all cases. Anybody adding option to rm to do exactly this? Pavel -- I'm really [EMAIL PROTECTED] Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Re: (fwd) Re: d_path or way to get full pathname
On Mon, 6 Dec 1999, Petr Vandrovec Ing. VTEI wrote: > That's a problem. But you should not pass deleted path into d_path, Well, I am (attempting) to write a filesystem which may dynamically create files. It looks that when the file doesn't (yet) exist, I get the (deleted) added. I could handle this by calling d_path() on the directory, then strcat()ing the new data. I found the function I wrote to be cleaner (at least for my application). I take note of all suggestions and maybe I can use them.
(fwd) Re: d_path or way to get full pathname
> I probably missed something important, but what's wrong with > approach d_path() is using now - returning pointer into middle of buffer? The lack of precize documentation. The fact that it's not obvious (at least to me) what happens if the buffer is too small. And the fact that the routine seem to add " (deleted)" in some cases to the buffer, to my knowledge in a way you can't easily know if it's part of the file name or not. > returned_path_pointer = d_path(dentry, buffer, buffer_length); > len = buffer + buffer_length - returned_path_pointer That can be useful, however, and that will not need the additional memory move I do in my version.
Re: (fwd) Re: d_path or way to get full pathname
On 6 Dec 99 at 20:07, Marc SCHAEFER wrote: > > I probably missed something important, but what's wrong with > > approach d_path() is using now - returning pointer into middle of buffer? > The lack of precize documentation. The fact that it's not obvious (at > least to me) what happens if the buffer is too small. Only part which fit into buffer is returned. But if you have path which is longer than MAX_PATH_LEN, you are in big troubles. You cannot pass this path back to kernel :-( > And the fact > that the routine seem to add " (deleted)" in some cases to the > buffer, to my knowledge in a way you can't easily know if it's > part of the file name or not. That's a problem. But you should not pass deleted path into d_path, as result is meaningless then. Sometime ago there was discussion to change format from / (deleted) to deleted:/ as string returned from d_path normally always start with slash. But some peoples thought that it could break ps-tools, fuser and other simillar programs. Best regards, Petr Vandrovec [EMAIL PROTECTED]
Re: d_path or way to get full pathname
On 6 Dec 99 at 12:10, Erez Zadok wrote: > - a faster method than constant shifting of the bytes. This is a serious > one. If you keep shifting bytes for each component, your complexity is > O(n^2). You can make it 2*O(n) as follows: > (1) first, scan the dentrys and their parents in reverse, cross mount > points as needed. > (2) sum up the total number of bytes needed, from the q_str structures. > (3) allocate the correct number of bytes (or verify that the user passed > enough space) > (4) repeat the reverse traversal, but this time, copy the bytes into the > output buffer directly at their offsets into the buffer (don't copy > any terminating nulls so you won't trash the beginning of the > component that followed). I probably missed something important, but what's wrong with approach d_path() is using now - returning pointer into middle of buffer? Walking list twice is going to be nightmare if we ever make dcache multithreaded. In most cases you want to copy path somewhere anyway, so it is not important whether it ends in the middle of buffer or at the beginning. Also, as sideeffect of current approach, you can get path length quickly by simple doing returned_path_pointer = d_path(dentry, buffer, buffer_length); len = buffer + buffer_length - returned_path_pointer Best regards, Petr Vandrovec [EMAIL PROTECTED]
Re: d_path or way to get full pathname
Marc, regarding your dentry full pathname function (and Serge's): I've not yet looked at either in detail but what I think is needed (assuming it's not there already) is this: - a flag to pass to the function: if true, returns full path names starting w/ a '/' and crossing mount points. There are cases you want one behavior and cases for another. - if the flag is false, return relative pathname to this super_block - a faster method than constant shifting of the bytes. This is a serious one. If you keep shifting bytes for each component, your complexity is O(n^2). You can make it 2*O(n) as follows: (1) first, scan the dentrys and their parents in reverse, cross mount points as needed. (2) sum up the total number of bytes needed, from the q_str structures. (3) allocate the correct number of bytes (or verify that the user passed enough space) (4) repeat the reverse traversal, but this time, copy the bytes into the output buffer directly at their offsets into the buffer (don't copy any terminating nulls so you won't trash the beginning of the component that followed). I'll be happy to help anyone write or test such a version (I started something similar a while back). I think it would be a useful small addition to the kernel. Erez.
Re: d_path or way to get full pathname (fwd)
Posted with author's authorization.
-- Forwarded message --
Date: Mon, 6 Dec 1999 10:15:16 -0500
From: Serge E. Hallyn <[EMAIL PROTECTED]>
To: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: d_path or way to get full pathname
Just a note: It looks like you're not following mount points. I'm assuming
this must be what you want since I'm sure you would have noticed :)
Since you originally asked for code, (and since its always fun to see other
people's code) my version (which I began before you posted, but didn't bother
to fix until now) is attached. You can tell I didn't want to spend the time
shifting the buffer, so instead I limited myself to a 100-element pathname
(quick-and-dirty)
good day,
-serge
void dte_getfullname(struct dentry *d, char *dest, int destlen) {
struct dentry *tmp_dentry;
struct qstr *p[100];
int len, np, i;
dest[0]='\0'; dest[1]='\0';
*(dest+1)='\0';
if (!d) return;
tmp_dentry=d; np=0;
*dest='/'; len=1;
while (tmp_dentry) {
if (tmp_dentry->d_name.len) {
if (!(tmp_dentry->d_name.len==1&&tmp_dentry->d_name.name[0]=='/')) {
len+=tmp_dentry->d_name.len+1;
p[np++]=&tmp_dentry->d_name;
if (len>=destlen || np>99)
return;
}
}
if (tmp_dentry==tmp_dentry->d_parent)
if (tmp_dentry==tmp_dentry->d_covers) tmp_dentry=NULL;
else tmp_dentry = tmp_dentry->d_covers;
else tmp_dentry = tmp_dentry->d_parent;
}
while (np--) {
*dest++='/';
for (i=0;ilen;i++) *dest++=p[np]->name[i];
*dest='\0';
}
}
Re: d_path or way to get full pathname
Posted with author's authorization -- Forwarded message -- Date: Mon, 6 Dec 1999 17:07:27 +0100 (MET) From: Marc SCHAEFER <[EMAIL PROTECTED]> To: Serge E. Hallyn <[EMAIL PROTECTED]> Subject: Re: d_path or way to get full pathname On Mon, 6 Dec 1999, Serge E. Hallyn wrote: > Just a note: It looks like you're not following mount points. I'm assuming > this must be what you want since I'm sure you would have noticed :) By this, do you mean that if a file is under /usr/truc/abcd/temp/file, and /usr/truc is really a mount-point of /dev/hda1, my function will only return abcd/temp/file ? If yes, this is an (undocumented) feature, yes, since I need the data relative to the current fs (the code is in a fs called mfs). > Since you originally asked for code, (and since its always fun to see other > people's code) my version (which I began before you posted, but didn't bother > to fix until now) is attached. You can tell I didn't want to spend the time > shifting the buffer, so instead I limited myself to a 100-element pathname > (quick-and-dirty) :) Would you mind posting your answer AND mine to [EMAIL PROTECTED] ? thanks
Re: Oops with ext3 journaling
Hi, On Sat, 4 Dec 1999 12:11:58 -0700, mike burrell <[EMAIL PROTECTED]> said: > couldn't you just make a new flag for the inode that journal.dat uses? i'm > guessing using S_IMMUTABLE will cause some problems, but something similar > to that? The immutable flag will work fine: journaling bypasses the normal file write mechanisms, so it will work with an "immutable" journal quite safely. --Stephen
Re: Oops with ext3 journaling
Hi, On Sat, 4 Dec 1999 08:44:46 -0800 (PST), Brion Vibber <[EMAIL PROTECTED]> said: > Maybe at least stick a nice big warning in the docs along the lines of > "do not write to your journal file while mounted with journaling on, > you big dummy!" :) Not that I'd do so deliberately of course, but it > might make people a little more wary later on. The README does > recommend setting the permissions to 400, but that doesn't protect > from root of course. "chattr +i journal.dat" will protect even from root. > Is there any reason you _would_ want to be able to write to the journal > file from userland while mounted? I'd guess no... No, and I'm pretty much convinced now that I'll move to having a private, hidden inode for the journal in the future. --Stephen
Re: Oops with ext3 journaling
On Sat, 4 Dec 1999, mike burrell wrote: > couldn't you just make a new flag for the inode that journal.dat uses? i'm > guessing using S_IMMUTABLE will cause some problems, but something similar > to that? I gate immutable a try on a loopbacked test fs and it seems to work fine... No complaints from the kernel, and it wrote to the journal file upon mount. Copies of the journal file before and after putting a bunch of files on the fs differed... and attempting to write to or copy over the journal file was denied even to root. Huzzah! So if you think you might accidentally overwrite your journal file, give it a chattr +i and stay safe... -- brion vibber ([EMAIL PROTECTED])
Re: (fwd) d_path or way to get full pathname
there is a document on VFS internals written and maintained by Neil Brown:
http://www.cse.unsw.edu.au/~neilb/oss/linux-commentary/
Regards,
--
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
On Sat, 4 Dec 1999, Marc SCHAEFER wrote:
> Hi,
>
> I am trying to find a way to get the full pathname from a dentry
> refering a file. I tried d_path(), and in one occasion I got
> nothing, and in the other I got rubbish, then the path
> I was expecting, and then (deleted).
>
> Also, I am trying to find a way to detect if the buffer
> was too small.
>
> Is there a general introduction on dentries somewhere ?
> I am persuaded it's going to be useful. Especially for
> the locking issues.
>
> This is under 2.2.12.
>
> PS: I *already* (gasp!) found the way to print it
> backwards by following d_parent until it's
> equal to dentry, however a standard function
> would presumably be better.
>
> Here is a code example:
>
> d_path(dentry,
> rq->request.path_name,
> sizeof(rq->request.path_name)); /* @@@ res ignored @@@ */
> #if 0
> if (some_cond_on_dpath_return_value()) {
> printk("mfs: mfs_com: pathname too long %d at %s.\n",
>this_length,
>dentry->d_name.name); /* @@@ really NUL term? @@@ */
> result = MFS_STATUS_OBJECT_NOT_FOUND;
> goto out_abort;
> }
> #endif
>
> printk("mfs_com: complete name: %s.\n",
> rq->request.path_name);
>
> thanks for any idea.
>
>
Re: Can't hardlink in different dirs. (BUG#826)
On Fri, 3 Dec 1999, Andrea Arcangeli wrote: > I want that the i_link of an inode can be changed only by an user that has > write permissions on the inode. I don't care if the permissions cames from > the uid/gid/other settings in the inode. > > I don't want an luser to increase the i_link of my inodes that he doesn't > have permission to change, to read to execute and to write. just my $0.001 - the above will look like what happens in UW7 (UnixWare 7) when MAC_ACCESS is active. I would hate to see such semantics to be default - the others (AV, Richard etc) are right, imho, because it would seem your proposal will irritate many people used to good old UNIX ways... Regards, -- Tigran A. Aivazian | http://www.sco.com Escalations Research Group | tel: +44-(0)1923-813796 Santa Cruz Operation Ltd | http://www.ocston.org/~tigran PS. UNIX security is perfect, the improvements should come from the heart...
